Version or commit hash:
Not sure, current head of foxy.
DDS implementation:
FastRTPS
Client library (if applicable):
Both cpp and python clients.
Steps to reproduce issue
We have two networks (N1 and N2) where two machines (M1 and M2) have interfaces and addresses on both of the networks. We are using a whitelist on M1 to prevent communication over N1.
Network N1, which provides internet access, was disconnected from M2. Apparently, M1 was attempting to send packets to M2 over N1 (which didn't work as it was disconnected, and violated its whitelist), but it instead manifested as huge (3 second) stalls in publish on ROS processes on M1. M2 may have been advertising to M1 over N2 to send data to its address on N1.
Put a different way, we whitelist one network card's IPs. But, if other machines that are not using a whitelist, for whatever reason, advertise a destination on the other network card... our whitelisted card will attempt to send packets to an impossible destination and will block the process while it tries to send. This manifests as huge, largely inscrutable delays. We found this by using wireshark on the UDP packets to see that the machine was trying to send data to the wrong network.
Expected behavior
Attempting to publish to bad destinations shouldn't block.
Machines shouldn't advertise disconnected network adapters as a destination to send packets to.
A machine communicating over network card N1 shouldn't ask other machines to send data to N2 (I would assume).
Bug report
Required Info:
Operating System: Linux
Installation type: Binaries. Foxy.
Version or commit hash: Not sure, current head of foxy.
DDS implementation: FastRTPS
Client library (if applicable): Both cpp and python clients.
Steps to reproduce issue
We have two networks (N1 and N2) where two machines (M1 and M2) have interfaces and addresses on both of the networks. We are using a whitelist on M1 to prevent communication over N1.
Network N1, which provides internet access, was disconnected from M2. Apparently, M1 was attempting to send packets to M2 over N1 (which didn't work as it was disconnected, and violated its whitelist), but it instead manifested as huge (3 second) stalls in publish on ROS processes on M1. M2 may have been advertising to M1 over N2 to send data to its address on N1.
Put a different way, we whitelist one network card's IPs. But, if other machines that are not using a whitelist, for whatever reason, advertise a destination on the other network card... our whitelisted card will attempt to send packets to an impossible destination and will block the process while it tries to send. This manifests as huge, largely inscrutable delays. We found this by using wireshark on the UDP packets to see that the machine was trying to send data to the wrong network.
Expected behavior
Attempting to publish to bad destinations shouldn't block.
Machines shouldn't advertise disconnected network adapters as a destination to send packets to.
A machine communicating over network card N1 shouldn't ask other machines to send data to N2 (I would assume).
Actual behavior