Internet out for 2 mins, RPi drops off local network and stays off

[jchh]

Creating a bug report/issue

Required Information

DietPi version | cat /boot/dietpi/.version

• G_DIETPI_VERSION_SUB=20
• G_DIETPI_VERSION_RC=1
• G_GITBRANCH=‘master’
• G_GITOWNER=‘MichaIng’
• G_LIVE_PATCH_STATUS[0]=‘applied’

Distro version | echo $G_DISTRO_NAME $G_RASPBIAN

• bullseye 0

Kernel version | uname -a

• Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

Architecture | dpkg --print-architecture

• arm64

SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

• RPi 4 Model B (aarch64)

Power supply used | (EG: 5V 1A RAVpower)

• 5V 3A
• Official Argon One power supply
• PI is in an Argon One case

SD card used | (EG: SanDisk ultra)

• using SSD
• Kingston SSDNow A400 240GB SATA 3 Solid State Drive (SA400S37/240G)

Additional Information (if applicable)

Software title | (EG: Nextcloud)

• docker: Homneassistant, Mosquitto, Z2M, Uptime-Kuma, Portainer

Was the software title installed freshly or updated/migrated?

• fresh install of everything ~4 weeks ago
• RPi/SSD also new ~4 weeks ago

Can this issue be replicated on a fresh installation of DietPi?

• no. I have an identical setup (except the cat) which does not experience this issue

← If you sent a “dietpi-bugreport”, please paste the ID here →

• Bug report ID | 4976c6df-ed57-426d-a1d3-060120c3f205

Steps to reproduce

1. Internet down for ~2 mins in middle if the night
2. RPi drops off the network (IP not visible from router)
3. All docker apps continue to run happily - just no internet access
4. sudo reboot and Pi is connected again

Expected behaviour

• Pi should stay connected to router

Actual behaviour

• Pi is losing connection to router if internet down for ~2-3 mins

Extra details

• Pi is connected to router via ethernet cable (LAN)
• This has happened twice in 4 weeks.
  • Last incident this morning
  • The previous one 12 days ago.
• The Pi runs 24/7
• My other Pi has never exhibited this problem
  • It is ~2 years old, also running 24/7.
  • Different location, but same router, same internet provider, same hardware and same software.
  • I have disconnected the Pi for a couple of minutes and it is fine.
  • I have switched off the router off for 5 mins and it is fine
  • I have disconnected the router from the internet, but left it powered and connected to the PI. The Pi is fine and remained connected.
• I do not know that this is a problem with the DIETPI software itself

[Joulinar]

do you use IPv6? Maybe the prefix changed but the Pi did not recognize? Can you check IP address assignment as soon as your Pi lost network connection?

ip a

[jchh]

Hi,

Thanks for replying!

I just did a router restart on both networks. The one with the problem did not reconnect after the router re4started. The one that is OK did reconnect after the router restarted,

I got the following on the Pi that loses connection:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d8:3a:dd:3c:0c:bf brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.101/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a00:23c5:6c3c:1801:da3a:ddff:fe3c:cbf/64 scope global dynamic mngtmpaddr 
       valid_lft 315359993sec preferred_lft 315359993sec
    inet6 fdaa:bbcc:ddee:0:da3a:ddff:fe3c:cbf/64 scope global dynamic mngtmpaddr 
       valid_lft forever preferred_lft forever
    inet6 fe80::da3a:ddff:fe3c:cbf/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:82:18:d4:ae brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
4: br-7548ab9f1166: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:24:a6:f7:3d brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-7548ab9f1166
       valid_lft forever preferred_lft forever
    inet6 fe80::42:24ff:fea6:f73d/64 scope link 
       valid_lft forever preferred_lft forever
6: veth3211aeb@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7548ab9f1166 state UP group default 
    link/ether 9e:09:83:64:2f:9a brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::9c09:83ff:fe64:2f9a/64 scope link 
       valid_lft forever preferred_lft forever
8: vethf5cfbca@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7548ab9f1166 state UP group default 
    link/ether 4a:56:32:e1:a0:af brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::4856:32ff:fee1:a0af/64 scope link 
       valid_lft forever preferred_lft forever
10: veth352618d@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7548ab9f1166 state UP group default 
    link/ether ee:6e:c4:5c:2a:63 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::ec6e:c4ff:fe5c:2a63/64 scope link 
       valid_lft forever preferred_lft forever
12: vetha9cc32c@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-7548ab9f1166 state UP group default 
    link/ether ce:72:20:da:a8:6a brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet6 fe80::cc72:20ff:feda:a86a/64 scope link 
       valid_lft forever preferred_lft forever

…and this on the Pi that does not:

root@DietPi:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:5f:01:39:6e:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd8e:b352:729e:4233:e65f:1ff:fe39:6ebe/64 scope global dynamic mngtmpaddr 
       valid_lft 1641sec preferred_lft 1641sec
    inet6 2a00:23c6:b200:601:e65f:1ff:fe39:6ebe/64 scope global dynamic mngtmpaddr 
       valid_lft 315359989sec preferred_lft 315359989sec
    inet6 fdaa:bbcc:ddee:0:e65f:1ff:fe39:6ebe/64 scope global dynamic mngtmpaddr 
       valid_lft forever preferred_lft forever
    inet6 fe80::e65f:1ff:fe39:6ebe/64 scope link 
       valid_lft forever preferred_lft forever
3: br-10ca778034c5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:35:27:ed:d6 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-10ca778034c5
       valid_lft forever preferred_lft forever
    inet6 fe80::42:35ff:fe27:edd6/64 scope link 
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:a9:ef:22:aa brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: br-ce1bef15ffe6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:2b:57:bc:bb brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-ce1bef15ffe6
       valid_lft forever preferred_lft forever
7: veth5764ac4@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-10ca778034c5 state UP group default 
    link/ether a2:98:b1:be:eb:88 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::a098:b1ff:febe:eb88/64 scope link 
       valid_lft forever preferred_lft forever
9: vethd151e61@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-10ca778034c5 state UP group default 
    link/ether fa:32:d0:11:61:d5 brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet6 fe80::f832:d0ff:fe11:61d5/64 scope link 
       valid_lft forever preferred_lft forever
11: veth7211678@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-10ca778034c5 state UP group default 
    link/ether 3e:22:c3:75:4a:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::3c22:c3ff:fe75:4ab9/64 scope link 
       valid_lft forever preferred_lft forever
13: veth681aead@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-10ca778034c5 state UP group default 
    link/ether 5a:d2:1f:9c:8a:a9 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::58d2:1fff:fe9c:8aa9/64 scope link 
       valid_lft forever preferred_lft forever
15: veth7f389b7@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-10ca778034c5 state UP group default 
    link/ether be:7a:c1:5c:6c:a1 brd ff:ff:ff:ff:ff:ff link-netnsid 4
    inet6 fe80::bc7a:c1ff:fe5c:6ca1/64 scope link 
       valid_lft forever preferred_lft forever

[jchh]

checking the routers, it appears both of them use IP6 (both with ULA enabled and stateless).

[Joulinar]

For testing, could you disable IPv6 on the problematic Pi and perform the test again?

[jchh]

I would happily do that, but I am not sure I can.

The only things I can do is switch of ULA:

and change allocation mode:

…will switching both of those off do it?

[Joulinar]

We miss understood. You can switch if IPv6 on the RPi itself. Just go into dietpi-config network settings.

[jchh]

I’ve just read this on the router forum - does it help?

BT don’t use Ipv6 for DNS, they get Ipv6 addresses via Ipv4 DNS.

[jchh]

@Joulinar

We miss understood. You can switch if IPv6 on the RPi itself. Just go into dietpi-config network settings.

got it - doing it now - thanks for clarifying!

Update:

• IPv6 is off
• router restarted
• PI did not rejoin the network when the router came back up
• power cycling the Pi got it back on the network

Also:

• the ‘good Pi’ also has IPv6 enabled.
• restarting the router did not change the IPv6 Global Unicast address or the Link local address for LAN or WAN

Update2:
not sure if this is relevant, but perusing through the settings shows the following differences between the 2 Pi’s:

	Bad Pi	Good Pi
I2C state	On	Off
SPI state	On	Off

[Joulinar]

On the Pi in question can you try to ping the router once it has been restarted? Keep IPv6 disabled for time being. Does the PRi shows LED activity on Ethernet interfaces?

[jchh]

The ‘bad’ PI is remote (at my mum’s address) and is all I can do to get here to switch it off and on again.

I can try when I next see her, but not sure when that will be.

would ping -c 2000 192.168.1.254 > ping.log do it?
(192.168.1.254 being my router)

forgot to add: I do have uptime-kuma installed and this is the error it showed when I restarted:

PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data. From 192.168.1.101 icmp_seq=1 Destination Host Unreachable --- 192.168.1.254 ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

edit: also noticed that, whilst my router has IPv6 details for Lan (and WAN), my Pi’s specific page says not…

[Joulinar]

we had a couple of causes in past where RPi lost network connection during router reboot. We where never able to replicate. Some users worked around by creating a script to reboot the Pi if connection to router is lost.

Out of curiosity, do you have a small switch/hub that could be places between Pi and router for testing??

Watchdog for Dietpi (Auto reboot if Internet is down)

I’m struggling with Wireguard on my raspberry pi4 on Dietpi. In combination with my Asus Router, i observed after manually restarting the Router, the Raspberry can’t catch up the internet connection. Everything is connected via Cable, no WiFi involved. Now I found that script and maybe someone with more expertise can tell, if this script works on Dietpi or not. Question 1: Also how should I adjust the script if I want to use the Ethernet connection and not WiFi as Interface. Question 2: H…

[jchh]

@Joulinar

ut of curiosity, do you have a small switch

I have a spare unmanaged switch if that’s what you mean?

I saw that thread as well - will do that as a last resort, but rather get to t(e bottom of it.

[Joulinar]

@jchh

I have a spare unmanaged switch if that’s what you mean?

that would be perfect for testing. My idea would be to use the switch to keep the Ethernet link up, even if the router is under reboot or similar.

[jchh]

OK, I’ll let you know when it is in place - will be a few days.

[Joulinar]

@jchh

will be a few days.

take your time

[jchh]

Can give you give me a list of tests* to run when I am there?

One obvious one is to restart the router, but what else should I test?

[edit: autocorrect fail*]

[Joulinar]

simply try to ping the router, once router has been rebooted. This is a basic check that needs to be working. Check if an IP address has been assigned (ip a)

[jchh]

not sure if you are online or not, but can’t start my pi with keyboard and HDMI cable connected (to use ip a) locally - just get a bunch of errors…

[Joulinar]

This looks bad, you have a disk connected, correct? This is the disk you are booting from? It seems to have bad data blocks.

How is the disk powered? With own PSU or just via RPi?