Troubleshooting visibility issues: one PC can see target, another can't

4 posts / 0 new
Last post
Offline
Last seen: 1 week 1 day ago
Joined: 03/12/2018
Posts: 32
Troubleshooting visibility issues: one PC can see target, another can't

I could really use some help.  I'm having trouble with a new laptop not being able to see DDS topics.

I have a linux test server, and some PCs that runs a client GUI.  They connect through a switch on a private network on DDS domain 3.

I have an older PC with only 5 network connections, and the private network connection is the third one down in a list of "netsh interface ipv4 show subinterface".  This seems to work fine and can communicate with the test server.

I also have a newer laptop with 8 network connections, and the private network connection is still the third one down in the same list.  However, I seem to have intermittent "visibility" problems from the laptop:

  • the admin console running on the laptop can see the test server's domain participant, but not the topics under it
  • the test server sees no data from the GUI running on the laptop when it sends data

Adding to the complexity and frustration:

  • rtiddsspy has no problem:  it sees my test server' subscriptions and published topics come and go appropriately as I start and stop the test server
  • once or twice, while bringing the test program up and down, I have seen the topics show up in the admin console.  So there appears to be some randomness in this.
  • If I remove the switch and connect the laptop directly to the test server, admin console can see the topics under the test server, but the test server still can't see data sent by the GUI

It really shouldn't be this hard, should it?

 

irwin's picture
Offline
Last seen: 3 weeks 1 day ago
Joined: 08/14/2010
Posts: 15

To start with what RTI DDS version are you using?

Older versions would only use the first 4 locators it sees as locators to announce. The way around this is ro use the allow filter to only use the interfaces to want.

This Knowledge base article shows how to do that:

https://community.rti.com/kb/how-do-i-restrict-rti-connext-use-only-subset-interfaces

 

Offline
Last seen: 1 week 1 day ago
Joined: 03/12/2018
Posts: 32

Thanks irwin.

This is version 5.4.0.

If I add allow_interfaces_list and deny_interfaces_list to the USER_QOS_PROFILES.xml, it doesn't seem to have any effect.

To be  clear, I add this to my linux test server, whose only network connection is 192.168.*:

  <qos_library name="CustomLibrary">
    <qos_profile name="Transmitter.Common" base_name="BuiltinQosLib::Generic.Common">
      <participant_qos>
        <transport_builtin>
          <mask>UDPv4</mask>
        </transport_builtin>
        <property>
          <value>
            <element>
              <name>dds.transport.UDPv4.builtin.parent.deny_interfaces_list</name>
              <value>10.*</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.builtin.parent.allow_interfaces_list</name>
                <value>192.*</value>
            </element>
          </value>        
        </property>
      </participant_qos>
    </qos_profile>

    <qos_profile name="User.TransmitterCommand" base_name="CustomLibrary::Transmitter.Common"/>
    <qos_profile name="User.TransmitterStatus"  base_name="CustomLibrary::Transmitter.Common"/>
    <qos_profile name="User.TransmitterReport"  base_name="CustomLibrary::Transmitter.Common"/>
  </qos_library>

The admin console on the PC sees this:

irwin's picture
Offline
Last seen: 3 weeks 1 day ago
Joined: 08/14/2010
Posts: 15

The WARNING that you see is that the Participant "TransmiterNode:1827" is getting a message from a remote endpoint( ie Participant, reader, Writer) because that application exited gracefully. But by the time this unregister command was received that remote Participant was deleted from its data base. That will happen if for some reason that remote Participant lost liveliness. It can loose liveliness due to a faulty IP connection or other program reason where that remote Participant cannot send its liveliness refresh massage. This is hard to isolate without having wire trace. 

   Also, your RTI revision of 5.4 cannot be. We have no such revision.

                          Irwin