homeskies / uw_fetch

Bringup and other robot dependent code
0 stars 0 forks source link

Configure a network tunnel device on astro #13

Closed nickswalker closed 4 years ago

nickswalker commented 4 years ago

We're starting to need Xavier data from client machines (discussed today with @vinitha910 @EdanSneh ), but the astro-xavier is behind NAT; this means that its IP address is only routable from astro. This prevents clients from receiving or publishing data to the Xavier, and breaks things like showing Xavier's topics in rviz.

One solution is to connect clients via ethernet directly to to the robot's LAN. Our machines only have a single network interface though, so they would lose their internet connection. To fix this, we would have to configure masquerading to share astros wifi connection with the client. This is not great, and it of course only works for one connected client at a time. Villa occasionally needed to do this to get enough bandwidth to debug perception things, and we'd have a switch hooked up to the robot to let a bunch of clients connect. Still, the default was a configuration that worked over wireless (i.e. the below).

The alternate solution is to set up a tunnel device between astro and each client. Villa used OpenVPN for this. Nowadays, wireguard is a better option. We could also use an authless tunnel, like a GRE.

In the meantime, anyone who needs to see data coming from Xavier over ROS needs to work directly on astro.

nickswalker commented 4 years ago

Turns out GRE tunnels are truly just point to point. Each client would require a new device on the robot, and then somehow routing would have to be set up to allow those devices to talk to eachother and the rest of the robot...

Wireguard is great. Installed it on astro without issues. Created a vanilla config, then set up a client with just a couple lines added. Client IPs need to be allocated statically and are tied to the client's key. We can't just set up a dozen machines with some fake keys, every new client would have to generate a key, then register with the robot and claim a free IP address. This is probably 3-4 hours worth of bash scripting to fully automate, but I won't because I expect only a couple will need to see topics from Xavier on client machines, and I can set those up myself.

Once a client is registered, it can magically resolve IPs in 10.42.42.0/24, the robot's subnet. No configuration change is necessary on the robot. It can continue running the master off of it's wlan0 public IP (which the client can resolve) and the Xavier can continue to use a ROS_IP that's in 10.42.42.0/24 (which now both astro and the client can resolve).

I'll track some basic configuration in the bringup package.