yarp
yarp copied to clipboard
robotology
yarp server & multiple eth interfaces
Some how related to #142
If we run the yarp server on a machine with 2 (or more) ethernet interfaces, it will handle connections on just one of them at time, but it is reachable from both.
Example: SRV machine has 2 eth connections: eth0 with IP 10.0.0.1 and eth1 with IP 192.168.1.1; and run the yarp server, which has 10.0.0.1 10000 as a conf file.
PC0 is connected to the eth0 of the SRV and has IP 10.0.0.20 PC1 is connected to the eth1 of the SRV machine and has IP 192.168.1.20
PC0 find the yarp server and opens a port /PC0_port (10.0.0.20 10001) PC1 also find the yarp server, ask for a name list and it gets /PC0_port 10.0.0.20 10.0.0.1
but the if PC1 wants to connect to /PC0_port it can't because PC1 is on a different subnetwork. It is correct, but a little misleading. The rational of the user is that if I can see a port from the name list, I should be able to connect to it, without the need of knowing the network topology. Right now I don't remember if PC1 can open a port and which IP that port will get. I think it can and it's address will be 192.168.1.20 10002 but should try.
my suggestion:
- yarp name list should return only connectable ports, i.e. ports on the same subnetwork/interface from which the request is coming
- Alternatively, if a connection is requested involving ports on different subnetworks, the server could detect this and start a new process doing the bridge. In this example this means opening, on the SRV machine, a port /from_PC0 on the eth0 interface and another one /to_PC1 on the eth1 interface, then establish the real connections between /PC0_port and /from_PC0 reading the data, and write them on the /to_PC1 /PC1_port connection. This will obviously consume more resource but maybe can be useful if we plan to make 2 robots interact somehow, where each robot has is own subnetwork, maybe already a lot of ports and data flow.
The first one is easier ;) Can the second one lead to network security issue?
Duplicate of #718 too. Anyway, yarpserver warns with you with a message when started with a non- standard configuration. This warning should be not ignored by the user.
I reopened this and closed #718, since bug number helps keep tracking how long we have been affected by this issue, so please keep the discussion on this.
As for this morning meeting, this could affect also the iCub + WiFi backpack system.
As long as Yarp server is started with the correct IP (the one given by the Wifi interface), no problems occur. If a user attempts to start yarp server on a machine/interface which is not the default one (the one set with yarp conf XXX YYY), a warning message is given to the user (NEVER force a yarpserver --write without asking why... on R1 _yarpserver --read is the solution... always 😄)
Finally, quoting my suggestion from #718:
We can add a file blacklist.conf where a list of ip addresses is written. When yarp server is started, if the ip address automatically chosen by the server (or chosen by the user in yarp.conf) matches one of the blacklisted addresses, an error message is displayed and yarp server terminates (the implementation should be pretty easy and straightforward) In this way the user is always notified if yarp server is accidentally started on the wrong network interface.