Multiple interfaces for gateway host

[stonier]

With two or more interfaces and no parameterised definition, we get:

[ERROR] [WallTime: 1386172023.059970] This machine is connected via multiple active interfaces. Detected: [('eth0', 1), ('tun0', 1)]. Please select a single interface using the network_interface param. Cannot send network information to hub.

I wonder if we can intelligently guess which interface by looking up ROS_HOSTNAME, ROS_IP and lastly ROS_MASTER_URI to choose the right one without having to set a parameter (still have that there as a last resort though).

Another way might be to work out an existing route through to a known hub to determine what interface it uses.

Note that if this is not set we get this issue later:

[WARN] [WallTime: 1386172058.158059] HubWatcherThread: Gateway Chatter Concert6a8569c9fcb24168b2ea3af47c30422c has been unavailable for 30.0 seconds! Marking as unavailable.
[WARN] [WallTime: 1386172058.158889] HubWatcherThread: Gateway dude1197f740da644a2bbe2188458b538c6a has been unavailable for 30.0 seconds! Marking as unavailable.
[WARN] [WallTime: 1386172058.159458] HubWatcherThread: Gateway dudebc7a085cf5fb4f44b5ff126225dc0610 has been unavailable for 30.0 seconds! Marking as unavailable.
[WARN] [WallTime: 1386172058.160028] HubWatcherThread: Gateway dudette220ecc7d681d4b10a2051b7935af16fc has been unavailable for 30.0 seconds! Marking as unavailable.

which is expected I guess.

[piyushk]

Err. So there is an undocumented network_interface param that can be used to select the interface. Do you think it needs to be further automated?

I can certainly put in code to make a guess as to the active interface, but here's why my use-case makes it difficult:

• The hub and the robot are not on the same network, so you cannot use the hub IP directly to make a guess.
• I plan to switch to DDNS soon, so ROS_IP is not set and ROS_HOSTNAME and ROS_MASTER_URI are useless.
• A traceroute to the Hub will probably work in practice, but traceroute doesn't tell you which interface is being used. I believe a combination of traceroute and route is theoretically sound in determining which interface is being used to connect to the hub. It just seemed like too much trouble.

Let me know which of these 3 options you would like me to add. Option 2 is the easiest, and should work with fixed IP addresses.

[stonier]

Yeah, it's fine for now. Just a thought for the future beyond the demo. There is so much configuration for multi-robot environments, I like to automate absolutely everything humanly possible, so long as I can guarantee it introduces no errors in esoteric use cases.

[piyushk]

I've finally decided on the fix for this problem. If we create a wrapper around route -n, we see the following output:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0

All we have to do is parse this output, figure out within which line the hub lies and pick out the interface. We'll need some special machinery to make sure that the loopback is not being used, as route does not report it.

[stonier]

👍 sounds worth trying.

[stonier]

I'm actually happy with the parameter configuration now. I usually set a roslaunch arg to trigger off an environment variable. We can leave it at that to save having to insert and maintain tricky code. Leave this as a todo?

[piyushk]

ok. changed milestone.