Communicatiin problem with virtual interfaces

4 posts / 0 new
Last post
Offline
Last seen: 5 years 9 months ago
Joined: 03/08/2013
Posts: 8
Communicatiin problem with virtual interfaces

Hi there,
I'm just having a weird problem that I cannot figure out myself, hoping for advise here:

I have two computers in the same local subnet 192.168.0.*. One of these computers has multiple IP-addresses for its only network interface defined: 192.168.0.11 and 192.168.1.11. When I run rtiddsping, I can see the discovery working, but the subscriber node does not receive any messages.

When I assign a single static IP instead, everything works (unfortunately this is not an option for me). Attached are the verbosity 5 logs for the rtiddsping on sender and receiver side. There are clearly messages stating "send failed:", but without any hint for the reason.

Any help is appreciated,

Thanks, Ulrich

 

AttachmentSize
Plain text icon dds_debug_receiver.txt127.25 KB
Plain text icon dds_debug_sender.txt78.99 KB
Organization:
rip
rip's picture
Offline
Last seen: 4 days 9 hours ago
Joined: 04/06/2012
Posts: 322

Hi Ulrich,

Those 'send failed', since they are on both the receiver and the sender logs, may simply be the discovery packets to remote ports that aren't bound to participants.

You don't say which of the machines has both 00.11 and 01.11, the publisher or subscriber.  You also don't provide how many interfaces the machines have, total.  We only use the first four valid interfaces.  It would be interesting to know if Discovery is completing.  

What do Analyzer or Admin Console show?  Do they show the participant, but not the endpoints?

Let me know if you've solved it in the meantime, and if so what you did.

 

rip

Offline
Last seen: 5 years 9 months ago
Joined: 03/08/2013
Posts: 8

Hi,
here are some more details:

  • PC0:
    • 2 physical wired interfaces, IPs *.00.40 and *.01.40
    • DDS communication allowed only on *.01.40 via dds.transport.UDPv4.builtin.parent.allow_interfaces (not relevant for rtiddsspy, since this option is set via C++ API and NOT in the qos)
  • PC1:
    • 1 physical wired interface eth0, 1 physical wireless interface wlan0
    • 1 dhcp adress on eth0
    • 2 additional IP addresses *.00.11 and *.01.11 specified for eth0 via linux network manager

Rtianalyzer output look like this:

  • Analyzer run on PC0: PC1 is not seen
  • Analyzer run on PC1: Participants on PC0 are listed, but without topics (that should be there)

Rtiddsping shows similar results: rtiddsping run on PC1 recognizes joining publisher and subscriber from PC0 but not the other way round.


After a little investigation with tcpdump, it seems like PC1 sends out multicast discoveries from its public dhcp adress.
There are also packets going from PC1 -> PC0 like these: PC1.40894 > PC0.7410: UDP, length 64

So the question is probably, how do I tell PC1 to send out its multicast packets via the static IP instead of the public dhcp.

Thanks, Ulrich

rip
rip's picture
Offline
Last seen: 4 days 9 hours ago
Joined: 04/06/2012
Posts: 322

Hi Ulrich,

I don't believe this is a tested configuration.  This may not work.  Also, which version of the libraries are you using?

There was a new feature added for 5.1, that allows a participant to announce a specific IP address as the return route -- this is expected to be used when the UDP is going to be returning via the "public" address when there is a NAT router involved.

I think it should be possible to use that same code path to designate the static IP address as the return route.

See section 7.1 of the "What's New" document (in ${NDDSHOME}/doc/pdf), to get started.

rip