[Reach M+] Change cdc_ether IP subnet

Hi, I’ve found Emlid is not very inclined to open any kind of static IP configuration on the emlid devices.

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”.

Im using this device to connect with a wire and it works good . the device itself gets the ip address rather than reach

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?

your network router should give this device an ip address and then you access it via that instead of the reach ip

Here Supported USB to Ethernet Adapters for M2 and RS2

I probably forgot to mention we’re using Reach M+ which doesn’t seem to have this functionality. I edited the title of this post to explicitly mention it.

ok

Hi Martin,

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.

2 Likes

Hi Martin,

Thank you for sharing this outstanding outcome! I always admire how our users apply their programming skills to get the desirable from our devices :sunglasses:

I believe that your code can be useful for some use cases, and it will be definitely appreciated :smiling_face:

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.