Connectivity issue over closed wireless network

8 posts / 0 new
Log in or register to post comments
Last post
Sun, 12/31/2017 - 23:59
#1
Kevin Triplett
Offline
Last seen: 6 years 10 months ago
Joined: 12/30/2017
Posts: 5
Connectivity issue over closed wireless network

This is my first experience with DDS, evaluating it as part of an open process automation initiative.

I have a Pi-based device publishing data to a Linux app subscriber and all works well on a private wireless network. On a closed, corporate wireless network which I have no control over, I am getting no connectivity, with the same system. I'm able to ping and ssh, so I know there's connectivity between the two.

I'm using the community-based rticonnextdds-connector library. My XML file is attached. Thanks for any help.

AttachmentSize
File board.xml2.87 KB
Keywords:
Top
Fri, 01/05/2018 - 03:27
ajimenez
ajimenez's picture
Offline
Last seen: 2 years 4 months ago
Joined: 09/29/2017
Posts: 21

Hi Kevin,

As you have said, you are facing a connectivity issue. It is possible that you need to add the initial_peers with the IPs of your devices.
Initial peers are necessary to find other participants in the same DDS domain.

 <participant_qos> 
     <discovery>
         <initial_peers>
             <element>239.255.0.1</element>
             <element>4@builtin.udpv4://127.0.0.1</element>
             <element>builtin.shmem://</element>
             <element>IP_linux_device</element>
             <element>IP_pi_device</element>
         </initial_peers>
     </discovery>
 </participant_qos>

Let me know if they are able to communicate now.

In regard to your question about ports, you can find more information in this knowledge base article.

It described the port used by RTI Connext DDS.

You should verify if the used ports are open up.

Let me know if you need more information about this topic.

Best,
Antonio

Top
Sun, 01/07/2018 - 02:37
Kevin Triplett
Offline
Last seen: 6 years 10 months ago
Joined: 12/30/2017
Posts: 5

Edit: See next post -- I'm able to temporarily get samples transferred over the corporate network by initiating the connection via peer-to-peer Ethernet connection.

Thank you for responding Antonio,

Unfortunately, I have no control over the corporate guest network that I'm using -- and it uses DHCP so I can't even assign IP addresses manually.

Top
Sun, 01/07/2018 - 19:40
Kevin Triplett
Offline
Last seen: 6 years 10 months ago
Joined: 12/30/2017
Posts: 5

Antonio,

edit: disregard this post, see next post.

Running wireshark with the Pi board wireless IP address as filter, I see some interesting information. Here are the steps and the results:

  1. Reboot the Pi board, Wireshark captures ARP packets from the Pi board (via wireless)
  2. The writer app starts, zero packets captured by Wireshark
  3. Run the reader on the Linux box, zero packets captured by Wireshark
  4. Connect the Ethernet cable from Pi to Linux, zero packets captured by Wireshark
  5. Restart the reader (writer still running), UDP packets captured by Wireshark
    1. Reader is now receiving packets
    2. Packets indicate source is Pi wireless IP and destination is Linux wireless IP
    3. Src port is 40976, dst port is 7411
  6. Disconnect the Ethernet cable, packets still captured
    1. Reader is still receiving samples
    2. This continues for about 156 seconds (samples are written every two seconds)
    3. Reader stops receiving data
  7. Reconnect the Ethernet, and after about 10 seconds, reader starts receiving samples again
  8. Disconnect the Ethernet, reader receives samples for about 150 seconds again
  9. Everytime I connect/disconnect the Ethernet cable, I see the ACKNACK and HEARTBEAT packets

Why would data transfer temporarily be possible only when the peer-to-peer link is established and why does it stop after about 150 seconds? Thanks for any help on this.

Edit: when copper Ethernet is connected/disconnected, Wireshark captures ACKNACK and HEARTBEAT messages. But only on connect/disconnect, no other times.

File Attachments: 
Image icon wireshark screenshot
Plain text icon wireshark packet dissection (plain text)
Top
Mon, 01/08/2018 - 22:41
Kevin Triplett
Offline
Last seen: 6 years 10 months ago
Joined: 12/30/2017
Posts: 5

New day, new information...

It appears I'm dealing with a discovery issue. Using your initial_peers configuration, I can establish connectivity. But I need a different approach since IP addresses on the network are dynamic.

Running "tcpdump multicast or broadcast and not arp" on each device, I see the discovery packets leaving but no packets arriving. Seems strange because I can ping each address (239.255.0.1 and x.x.255.255 respectively). I'm not sure what to try next.

I'll continue researching, but I may need some guidance and any help is greatly appreciated. :)

Top
Tue, 01/09/2018 - 08:57
ajimenez
ajimenez's picture
Offline
Last seen: 2 years 4 months ago
Joined: 09/29/2017
Posts: 21
Hi Kevin,
 
Firstly, you have done two tests on the same machines using different networks:
    - private wireless network (works)
        I consider they are doing the discovery through multicast, because loopback and shared memory will work only on the same machine.
    - corporate wireless network (does not work)
 
The discovery cannot be done on the corporate wireless network for two reasons:
    - A firewall does not allow packets on the required UDP port through the firewall. More information in the knowledge base article. 
    - Multicast is not allowed through the network (maybe in a router between the machines). You can test multicast connectivity with iperf3, step.
 
Let me know the status of the issue.
 
Best,
Antonio
Top
Wed, 01/10/2018 - 01:58
Kevin Triplett
Offline
Last seen: 6 years 10 months ago
Joined: 12/30/2017
Posts: 5

You're right, thank you Antonio, iperf was what I needed to confirm. The corporate wireless is blocking the multicast packets, whereas my private network passes these packets along and everything is fine.

I believe this is probably a brick wall, since I can't change the firewall easily and can't control what IP addresses are assigned (although IT might be willing to assign some, depending on the DHCP range setting -- I'll check this next).

Thanks,
Kevin

Top
Wed, 01/17/2018 - 15:12
sumeet_rti
Offline
Last seen: 6 years 3 months ago
Joined: 01/31/2011
Posts: 37

Hi Kevin,

Did you see that initial peers can be updated at runtime using DomainParticipant::add_peer()? One approach would involve:

  1. start your application
  2. retrieve your IP address
  3. register your IP address with a service
  4. lookup the registered IP address of other peers, and add them as peers using add_peer().
  5. other peers can find your address as needed, and add you as a peer

There's some non-trivial work involved beyond the above: notifications when new peers register, managing the service, etc. Or you can just use the RTI Cloud Discovery Service. From the description:

"RTI Cloud Discovery Service is a stand-alone application needed to deploy RTI Connext® DDS applications in dynamic environments where UDP/IP multicast is not available. This is typical of wide area networks or some cloud-based environments where the routers and switches may disable IP multicast forwarding."

 

For dynamic environments where the network addresses are not known in advance, or in cases where the list is too large or cumbersome to manage, you can leverage RTI Cloud Discovery Service. This external service acts as a reliable “rendezvous” point for Connext DDS applications to learn the presence and network addresses of other DDS applications. This can be accomplished by setting the Initial Peers to include Cloud Discovery Service.

It's a part of RTI Labs, our place for experimental products. We're always looking for feedback, so let us know if it works for you.

Cheers,

-sumeet

Top