Ethernet interface not going up again (with "ifconfig eth0 up", on Rpi3)

Product support
, ,
1

Hi everybody,

we have a setup with four “Services” containers running on a Raspberry Pi 3 that is connected to the internet with a LAN cable.
This works fine and I am very happy with the quick and ordered deployment with resin.

However one thing has confused me for a few days:

When I am in a terminal within one of our services,
the internet connection does not really go up and down with ifconfig.

  1. When I use “ifconfig eth0 down”, the device stays online in the resin interface.
    The only thing that turns different is, that I cannot ping anything anymore from the device.
  2. When I use “ifconfig eth0 up”, I still cannot ping anything anymore from the device.

I made a short script to illustrate that:

root@raspberrypi3:/# cat pingtest.sh
#!/bin/bash
echo “Basic ping”
ping -c 3 8.8.8.8

echo “Take network interface down, then ping”
ifconfig eth0 down
sleep 5
ping -c 3 8.8.8.8

echo “Take network interface up, then ping”
ifconfig eth0 up
sleep 5
ping -c 3 8.8.8.8

echo “done”

Here is the output I get with that:

root@raspberrypi3:/# . pingtest.sh
Basic ping
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=21.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=20.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=20.3 ms

— 8.8.8.8 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 20.350/20.823/21.641/0.592 ms
Take network interface down, then ping
connect: Network is unreachable
Take network interface up, then ping
connect: Network is unreachable
done

So is there an fundamental difference in the way resin OS handles network connections?
Or am I doing something wrong?

I would be very thankful if somebody could point me towards the right resources.

Thanks!
Chris

4

Hi TT,

The network it’s self is controlled via the HostOS, and unless you’ve specified that one of those services should run in permissive mode, they wouldn’t actually have access to hardware or device controls.

That said, networking on ResinOS is controlled via NetworkManager, and can be controlled from the containers via a DBUS connection to the HostOS, details are available at:

https://docs.resin.io/reference/resinOS/network/2.x/#changing-the-network-at-runtime
and

Hope that helps!

1 Like
5

Hi @chrischabot,

thanks a lot for the information.
The documentation is very helpful.

Is there an overview somewhere of what Resin is doing (or not doing) to maintain network connections?
I am trying to get a sense about which points of failiure I will have to take into account in my own code and what already safely works out of the box.

Greetings,
Chris

6

Heya – glad that was useful!

As we’re using NetworkManager, it’s documentation is a pretty good source for understanding how it behaves and manages connects / retries and so on: https://developer.gnome.org/NetworkManager/stable/

https://docs.resin.io/reference/resinOS/network/2.x/#introduction has a pretty decent high level overview, in general as long as autoconnect is set to true, it’ll try to connect to the network as soon as a connection drops.

Hope that helps give you some more insight ?

7

Hey, thanks again!

I was looking for the weird reconnection routines, like switching USB power or rebooting if nothing works.
Basically like these guys are doing it in their project:


Do you think that is a good idea to implement?
Are there similar features already in resin OS?

Or is the “default” Network manager switching the only thing going on?

Anyways, thanks a lot for your fast and kind responses! :slight_smile:

Greetings,
Chris

8

Ah yes that really depends on the hardware.

In most cases the network manager will just do a regular reconnect – some cellular modems are a bit more finicky though and need a real hard reset to come online again (the “Have you tried turning it off, and on again” approach).

So in most cases, provided the hardware is stable and not to finicky, you should be fine with the default setup – otherwise a cronjob that checks the network and issues a device reboot over the DBUS connection, or something more complicated like the above if device reboots are sub-optimal, are great work-arounds.

1 Like