Bind to non default interface

[garyservin]

If you want to use something that isn't the default route ( e.g. Ethernet for internet, but WiFi for the multimaster network), you need to be able to specify the network to bind to. By default multimaster binds to the default interface and will not discover other masters in the case outlined above.

This PR addresses the previous use case and allows multimaster_fkie to bind to a non default interface by specifying the interface via a ROS param ('~interface') or by setting the ROS_IP envvar.

Some other changes introduced

• added a second listener socket (unicast) to allow for unicast UDP traffic to be received, since we were unable to send unicast traffic with the same multicast socket.
• Don't exit if we're on localhost, just log a warning
• Added support for different logging levels in master_monitor: currently all logs are marked as warnings, where some should be marked as errors.

[atiderko]

Thanks for the pull request, @garyservin.
The possibility to specify an interface by ~interface parameter or by ROS_IP is already available since 0c7302d (XMLRPCServer listen on all address if it binds to 0.0.0.0)
Unfortunately it is neither documented in ROS wiki nor by launch file :-(

Your PR have some useful changes, like

• Don't exit if we're on localhost, just log a warning
• Added support for different logging levels in master_monitor: currently all logs are marked as warnings, where some should be marked as errors.

But it also removes the discovery functionality specified by ~robot_hosts. These robots are pinged using unicast communication because in some network environments multicast does not work properly.

Can you explain why you are unable to send unicast traffic with the same multicast socket?

regards
atiderko

[mikeodr]

Hi @atiderko,

While trying to use the ~interface or ROS_IP parameters for attempting to bind to a specific interface I found that it wasn't working. After some deep diving with wireshark I had to fix how it actually bound to the interface here

A few use cases we found this helped address for us are:

• Binding to a non-default interface. (wasn't working)
• Logging changes to be more realistic.

Is there any documentation on the ~robot_hosts param, this may be of some use to us in the near future also if I am understanding it's functionality properly.

[atiderko]

Hi @mikeodr,

there is currently no documentation how ~robot_hosts/discovering internally works.
When ~robot_hosts should be used:

• the underlining network has no multicast support (e.g. LTE)

How it works:

• ~robot_hosts is a list of remote hosts described by name or IP
• in addition to multicast heartbeat an unicast message with request to send a heartbeat message by unicast will be sent to each host in ~robot_hosts
  • if a new request or a new heartbeat message (unicast or multicast) is received the master_discovery contacts the XMLRPCServer on sender host to get additional informations about remote ROS environment (masteruri, mastername, nodename). In most cases the masteruri contains the name of the host. This hostname should be resolved to the same IP (on local machine and on remote host)!
  • after the additional informations are received, the remote master_discovery is registered and is available through the published topic.
• the unicast message with request is also sent if while a predefined interval of (ACTIVE_REQUEST_AFTER=60 sec) no heartbeats are received from remote host
  • this is useful in VLANs because some Linux hosts lost the group membership
  • it is also useful if heartbeats are deactivated to reduce network traffic
• if heartbeats are deactivated (HEARTBEAT_HZ==0) multicast/unicast messages are sent on ROS -Master changes

I hope this helps to understand the discovery process with multicast and unicast messages.

Did you tried to change the default multicast route to a non default interface (in combination with current implementation of ~interface)?
Perhaps this document contain some hints for network configuration: http://www.iri.upc.edu/files/scidoc/1607-Multi-master-ROS-systems.pdf

I will also try to setup an environment with multiple interfaces and test the behavior again...

regards,
atiderko

[atiderko]

Hi @mikeodr,
I reproduced the problem with non default interface. I try to integrate your solution.

regards,
atiderko

[atiderko]

Hi @mikeodr, @garyservin,

I've integrated your solution with some changes to be able to use the unicast in the currently used manner. Can you test it in your environment, please?

regards,
atiderko

[garyservin]

@atiderko thanks for integrating the changes. I've tested and I can bind to a specific interface now.

Also, would you be able to release new version with these changes?

Thanks!

[atiderko]

@garyservin thanks for tests and good news!

I will release the new version, but it will take a while before the public repositories are synchronized. Last sync was 7 days ago.

[paulbovbel]

@atiderko, if you wouldn't mind cutting a release, we can get it built and available on our public package server (packages.clearpathrobotics.com) for more immediate testing.

[atiderko]

@paulbovbel I have no problem to release it also on your repository as long as it does not conflicts with public ros repositories. What do I have to do?

[paulbovbel]

Nothing needs doing, other than creating the tag you made. The newest version is now available on packages.clearpathrobotics.com, and we'll work it into our testing pipeline (FYI @garyservin)

clearpathrobotics/public-rosdistro@3d222eb

[atiderko]

@paulbovbel thanks, that was easy and works well : -)