Force the eth0 to be the default network route

Project help
1

Hi,
Is it possible to force the eth0 to be the default network route?

We have two devices that randomly loosing connection to the balena cloud.
The devices are still answering to ping…

My consern is that, we are using a USB scanner that for sone reason are creating a virtual network device.
So in the cloud dashboard I can see two local IP addresses.

My suspicion are that sometimes the device are thinking that the virtual network are the one to use?

2

Hi,

Have you tried setting ipv4.route-metric in your system-connection for eth0?
You could also try creating a system-connection for the USB scanner, and add ipv4.never-default.

See here for more details.

1 Like
3

Hi @TJvV

No i have not…

Is it possible to do that remote? There are a long way to the device…

4

You can also check with ip route on a live device through a terminal to see whether there is a default route configured for the USB scanner and also what the route metric is for it.

The ipv4.route-metric and ipv4.never-defaultsettings can be modified remotely indeed. Either by using nmcli or by changing an already configured NetworkManager connection profile.

You can use for example nmcli c edit or nmcli c modify to change existing connection settings.

Please note that it is best to try those things out on a test device and practice a bit before applying changes on a production device as it may leave the device with permanent connectivity problems.

1 Like
5

Hi @majorz

Running ip route get’s this info for the USB scanner and eth0:

default via 192.168.10.1 dev eth0  src 192.168.10.179  metric 100 
default via 172.16.1.1 dev usb0  src 172.16.135.222  metric 20101 
10.114.101.0/24 dev balena0 scope link  src 10.114.101.1 
10.114.102.0/24 dev resin-dns scope link  src 10.114.102.1 
10.114.104.0/25 dev supervisor0 scope link  src 10.114.104.1 
52.4.252.97 dev resin-vpn scope link  src 10.242.153.211 
172.16.0.0/16 dev usb0 scope link  src 172.16.135.222  metric 101 
172.17.0.0/16 dev br-ca338bde8816 scope link  src 172.17.0.1 
192.168.10.0/23 dev eth0 scope link  src 192.168.10.179  metric 100

On this device the connection works fine… But on the other device there are no connection, until several reboots.

6

I see, the usb0 should not be marked as default route. You may try changing the settings of the USB connection to ipv4.never-default=true. What probably happens is that metrics could be inverted on some of the reboots, so never-default setting is needed. Basically never-default specifies whether an interface should provide Internet connectivity or not.

1 Like
7

Randomly, a couple of my devices seem to lose their connection to the Balena cloud, despite still responding to ping requests. This has been a source of frustration as it disrupts my deployment workflow. I suspect that a USB scanner attached to one of the devices is causing the problem by creating a virtual network device. This is evident in the cloud dashboard, where I notice two local IP addresses. It’s possible that the devices are intermittently selecting the virtual network for communication.

8

Hello @Jesper did this solution work for you? Let us know if that fixed your issues!

Thank you!

10

Hi @mpous

Yes, this did solve the problem, and the devices are running as expected now. :slight_smile:

11

Thanks for the confirmation @Jesper

Let us know if we can help you more!

13

Hey there,

Munira here, Sounds like a tricky situation you’re in. I’ve seen something similar before, where virtual network devices unintentionally take over as the primary route for network traffic. If you want to ensure that eth0 remains as the default network route, here are some steps you can follow:

Set Metric for eth0:
You can prioritize eth0 by assigning a lower metric. This ensures that eth0 has a higher preference over other interfaces.

Edit /etc/network/interfaces or the relevant configuration file depending on your system.
Under the eth0 configuration, add:
csharp
Copy code
up ip route add default via <gateway_ip> dev eth0 metric 10
Replace <gateway_ip> with the actual gateway IP for eth0.
Restart the network service.
Delete Unwanted Routes:
If you want to ensure that traffic doesn’t take a route through the virtual network:

Check the routing table using route -n or ip route show.
Delete any default routes not associated with eth0 using route del default gw <gateway_ip> or ip route del default via <gateway_ip>.
Disable Automatic Configuration for Virtual Interface:
If you find that the virtual network device gets its own DHCP configuration which interferes with eth0, you might want to configure it for manual/static IP or entirely disable its network capabilities.

Make sure you test these changes in a controlled environment before deploying to all devices to ensure there’s no unintentional disruption.

If you’re not already, you might also consider reaching out to the balena Cloud support or community. They’re usually pretty savvy about these issues, and might have some device-specific recommendations for you.

Hope this helps! Let me know if you have any more questions.

Cheers,
Munira

1 Like