I’ll ask about something a bit different - the chosen IP subnet 192.168.2.0/24 collides precisely with the subnet we use on our devices, so when the GPS is connected via USB to a Linux computer, it creates the cdc_ether device that steals connection to our local network and makes the computer unreachable. My question is - would it be possible to at least configure the IP subnet of the cdc_ether interface?
So far, we disable this interface using udev rules, but that’s a pity, because I’d rather connect the unit to the Internet via a wire than via wifi.
I know that we could probably set some kind of NAT on the computer, but we’d like to keep the config as simple as possible. I’m also not sure whether it is possible to “NAT DHCP messages”.
I don’t understand. Even if the device had an integrated router, Reach M+ runs a DHCP server and not a DHCP client on the wired interface. So it will still appear at its own selected address in the 192.168.2.0/24 subnet. Or am I missing something?
Here in this topic one of our users tells that he was able to connect LAN adapter with Reach M+. It should work with TP-Link UE200 adapter. You can connect Reach to the Internet via Ethernet cable and LAN adapter while it’s in the hotspot mode. It gives a static IP to Reach. I attached the indicative scheme.
Thank you for confirming it is also possible with M+, Kirill. This solution looks interesting, although it is not ideal as it increases the size the GPS solution takes in the robot, and requires a free Ethernet port, which is a scarce resource. Connecting via the onboard USB and its provided cdc_ether device would still be the preferred option.
After lots of pondering, I came up with a solution that would allow us to safely connect M+ to our robot without being scared that it will mess up our networking (which is on a colliding subnet), while keeping the device accessible on a different IP address/subnet.
The solution makes use of network namespaces - it puts the cdc_ether interface into a namespace, effectively hiding it from the rest of the system, and creates a 1:1 NAT to the hidden device from the host system. The host is connected to the M+ using a static IP address, ignoring its DHCP server. The DHCP packets are not visible on the host. Other devices on the network can access selected TCP ports of the M+ using port forwarding.