Weird WIFI drop on a RPi 4

unixorn · 9 February 2023 17:38

Creating a bug report/issue

Required Information

DietPi version | 8.13.2
Distro version | bullseye 0
Kernel version | Linux kraken.REMOVED 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux
SBC model | RPi 4 Model B (aarch64)
Power supply used | Canakit 5.1V 3.5A
SD card used | ( SAMSUNG (MB-ME64GA/AM) 64GB 100MB/s (U3) MicroSDXC EVO Select)

Additional Information (if applicable)

Software title | N/A
Was the software title installed freshly or updated/migrated? Fresh default install + docker
Can this issue be replicated on a fresh installation of DietPi? Yes, I’ve redownloaded the img and reflashed the microSD card with the same results.
← If you sent a “dietpi-bugreport”, please paste the ID here →
Bug report ID | 15db2157-afa4-49c6-9878-b923986166d8

Steps to reproduce

Boot my rPi. Wait a few hours, try to ssh in, get “No route to host”
retry ping -c 1 kraken.ELIDED && ssh kraken.ELIDED and it will eventually respond to network again and allow me to ssh in. It doesn’t matter if I try to ssh from a host with wired ethernet or another one on the same wifi SSID.

Expected behaviour

It should always respond to the network.

Actual behaviour

Every so often it drops network temporarily. It’s hard to say how long or how often because I only notice it when I try to ssh into the rPi.

Extra details

It doesn’t matter if I have docker installed or not, I still see it fall off of wifi. I only have a dozen wifi devices, and I’m running unifi network gear with multiple APs.

When I connect from a Mac on the same WIFI network to the rPi to test, the two devices are at opposite ends of my desk, and the MBP is showing 3 bars of signal (the nearest AP is two meters below my desk).

The same thing happens whether or not a USB thumb drive is connected, and there are no other devices connected to the rPi to draw power.

…

Joulinar · 9 February 2023 20:21

we could try to get some logs. If you have access to your system again, can you check following.

journalctl -u ifup*

As well you could start our own service (dietpi-wifi-monitor) to monitor and reconnect WiFi connections if needed.

unixorn · 10 February 2023 01:46

I enabled and started dietpi-wifi-monitor, I’ll report back in a day or so to see what happens.

Unfortunately journalctl only gave me the info since the most recent boot, so I’ll capture that before I reboot again.

thelampcc · 10 February 2023 12:50

Hi there! I’m new to DietPi and this forum.

It looks like I’m having similar issues on a Zero 2W. WiFi keeps dropping. Weirdest thing is that I have noticed that logging in on the local console (keyboard and monitor attached) improves things immediately. For example if I SSH in to the Pi sometimes the connection times out, sometimes it connects but then everything will be awfully slow. Then if I leave the connection open and login as the dietpi user on the local console and return to the SSH console everything works as expected and the console isn’t slow anymore. Then when I logout from the local console the SSH console becomes slow again.

My workaround now is to keep the local console open. As long as I do this WiFi works great but once I close it WiFi is almost unusable.

I just did a fresh install of the latest DietPi software to confirm this issue and sure as well it immediately popped up again once I configured WiFi and logged out from the local console. Any ideas what could be causing this? Already looked at journalctl output but nothing to be seen there.

Just to be sure: my problem is that sometimes the WiFi connection has been dropped as reported by the owner of this thread and sometimes it’s just very very slow. And this only happens when there is noone logged in to the local console. Weird stuff.

Joulinar · 10 February 2023 16:19

I’m not aware of a case where system performance was influenced by local console login. @MichaIng do you recall such a situation?

MichaIng · 10 February 2023 17:25

I can only imagine that e.g. an autologin script/option triggers on TTY1 logins only and decreases performance, but the other way round? Can you check whether the WiFi power save option is disabled?

iw dev eth0 get power_save

@unixorn

Boot my rPi. Wait a few hours, try to ssh in, get “No route to host”

You see “No route to host” when trying to SSH from another system into the DietPi RPi? Because this error message indicates a client or network issue, not a server issue. It means that no route for the IP of the remote host has configured on the client, e.g. because the DHCP lease or IPv6 router advertisement timed out. On the client, assure that ip r and in case ip -6 r contain a route for the RPi’s IP address. Compare IPv4 and IPv6:

ping -4 -c 1 kraken.ELIDED
ping -6 -c 1 kraken.ELIDED

thelampcc · 12 February 2023 14:52

I know it’s weird that a login on the local console has this effect. I’ve been a Linux sysadmin and LAMP systems architect for 20+ years and I have never seen this before. It is very consistent though. If I logout from the local console existing and new SSH sessions become very very sluggish.

It’s not only client to service communication which starts failing though. I have Domoticz running on this Pi and that fails to contact other devices on the same WiFi network as well pretty soon after I close the local console login.

dietpi@pi-powerwall:~$ sudo iw dev wlan0 get power_save
Power save: off

thelampcc · 12 February 2023 14:57

I have enabled DietPi-WiFi_Monitor a few days ago. This is the only output from it before logging out from the local console:

Feb 10 15:21:12 pi-powerwall dietpi-wifi-monitor.sh[407]: [ INFO ] DietPi-WiFi_Monitor | Checking connection for wlan0 via ping to default gateway every 10 seconds

And this is the output I get immediately after logging out:

Feb 12 15:54:30 pi-powerwall dietpi-wifi-monitor.sh[407]: [ INFO ] DietPi-WiFi_Monitor | Detected wlan0 connection loss. Reconnecting...
Feb 12 15:54:31 pi-powerwall dietpi-wifi-monitor.sh[91900]: Killed old client process
Feb 12 15:54:32 pi-powerwall dietpi-wifi-monitor.sh[91900]: Internet Systems Consortium DHCP Client 4.4.1
Feb 12 15:54:32 pi-powerwall dietpi-wifi-monitor.sh[91900]: Copyright 2004-2018 Internet Systems Consortium.
Feb 12 15:54:32 pi-powerwall dietpi-wifi-monitor.sh[91900]: All rights reserved.
Feb 12 15:54:32 pi-powerwall dietpi-wifi-monitor.sh[91900]: For info, please visit https://www.isc.org/software/dhcp/
Feb 12 15:54:32 pi-powerwall dietpi-wifi-monitor.sh[91900]: Listening on LPF/wlan0/e4:5f:01:84:ae:76
Feb 12 15:54:32 pi-powerwall dietpi-wifi-monitor.sh[91900]: Sending on   LPF/wlan0/e4:5f:01:84:ae:76
Feb 12 15:54:32 pi-powerwall dietpi-wifi-monitor.sh[91900]: Sending on   Socket/fallback
Feb 12 15:54:32 pi-powerwall dietpi-wifi-monitor.sh[91900]: DHCPRELEASE of 172.16.0.105 on wlan0 to 172.16.0.1 port 67
Feb 12 15:54:34 pi-powerwall dietpi-wifi-monitor.sh[91947]: Internet Systems Consortium DHCP Client 4.4.1
Feb 12 15:54:34 pi-powerwall dietpi-wifi-monitor.sh[91947]: Copyright 2004-2018 Internet Systems Consortium.
Feb 12 15:54:34 pi-powerwall dietpi-wifi-monitor.sh[91947]: All rights reserved.
Feb 12 15:54:34 pi-powerwall dietpi-wifi-monitor.sh[91947]: For info, please visit https://www.isc.org/software/dhcp/
Feb 12 15:54:34 pi-powerwall dietpi-wifi-monitor.sh[91947]: Listening on LPF/wlan0/e4:5f:01:84:ae:76
Feb 12 15:54:34 pi-powerwall dietpi-wifi-monitor.sh[91947]: Sending on   LPF/wlan0/e4:5f:01:84:ae:76
Feb 12 15:54:34 pi-powerwall dietpi-wifi-monitor.sh[91947]: Sending on   Socket/fallback
Feb 12 15:54:34 pi-powerwall dietpi-wifi-monitor.sh[91947]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
Feb 12 15:54:38 pi-powerwall dietpi-wifi-monitor.sh[91947]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
Feb 12 15:54:47 pi-powerwall dietpi-wifi-monitor.sh[91947]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21
Feb 12 15:55:08 pi-powerwall dietpi-wifi-monitor.sh[91947]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21
Feb 12 15:55:29 pi-powerwall dietpi-wifi-monitor.sh[91947]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
Feb 12 15:55:35 pi-powerwall dietpi-wifi-monitor.sh[91947]: No DHCPOFFERS received.
Feb 12 15:55:35 pi-powerwall dietpi-wifi-monitor.sh[91947]: No working leases in persistent database - sleeping.
Feb 12 15:55:35 pi-powerwall dietpi-wifi-monitor.sh[407]: [  OK  ] DietPi-WiFi_Monitor | Completed
Feb 12 15:55:45 pi-powerwall dietpi-wifi-monitor.sh[91979]: [FAILED] DietPi-WiFi_Monitor | A default gateway on interface "wlan0" does not exist.
Feb 12 15:55:45 pi-powerwall dietpi-wifi-monitor.sh[407]: [ INFO ] DietPi-WiFi_Monitor | Detected wlan0 connection loss. Reconnecting...
Feb 12 15:55:45 pi-powerwall dietpi-wifi-monitor.sh[91992]: Killed old client process
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: Internet Systems Consortium DHCP Client 4.4.1
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: Copyright 2004-2018 Internet Systems Consortium.
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: All rights reserved.
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: For info, please visit https://www.isc.org/software/dhcp/
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: Listening on LPF/wlan0/e4:5f:01:84:ae:76
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: Sending on   LPF/wlan0/e4:5f:01:84:ae:76
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: Sending on   Socket/fallback
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: DHCPRELEASE of 172.16.0.105 on wlan0 to 172.16.0.1 port 67
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: send_packet: Network is unreachable
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: send_packet: please consult README file regarding broadcast address.
Feb 12 15:55:46 pi-powerwall dietpi-wifi-monitor.sh[91992]: dhclient.c:2879: Failed to send 300 byte long packet over fallback interface.
Feb 12 15:55:48 pi-powerwall dietpi-wifi-monitor.sh[92035]: Internet Systems Consortium DHCP Client 4.4.1
Feb 12 15:55:48 pi-powerwall dietpi-wifi-monitor.sh[92035]: Copyright 2004-2018 Internet Systems Consortium.
Feb 12 15:55:48 pi-powerwall dietpi-wifi-monitor.sh[92035]: All rights reserved.
Feb 12 15:55:48 pi-powerwall dietpi-wifi-monitor.sh[92035]: For info, please visit https://www.isc.org/software/dhcp/
Feb 12 15:55:48 pi-powerwall dietpi-wifi-monitor.sh[92035]: Listening on LPF/wlan0/e4:5f:01:84:ae:76
Feb 12 15:55:48 pi-powerwall dietpi-wifi-monitor.sh[92035]: Sending on   LPF/wlan0/e4:5f:01:84:ae:76
Feb 12 15:55:48 pi-powerwall dietpi-wifi-monitor.sh[92035]: Sending on   Socket/fallback
Feb 12 15:55:48 pi-powerwall dietpi-wifi-monitor.sh[92035]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
Feb 12 15:55:56 pi-powerwall dietpi-wifi-monitor.sh[92035]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
Feb 12 15:56:02 pi-powerwall dietpi-wifi-monitor.sh[92035]: DHCPOFFER of 172.16.0.105 from 172.16.0.1
Feb 12 15:56:02 pi-powerwall dietpi-wifi-monitor.sh[92035]: DHCPREQUEST for 172.16.0.105 on wlan0 to 255.255.255.255 port 67
Feb 12 15:56:05 pi-powerwall dietpi-wifi-monitor.sh[92035]: DHCPREQUEST for 172.16.0.105 on wlan0 to 255.255.255.255 port 67
Feb 12 15:56:09 pi-powerwall dietpi-wifi-monitor.sh[92035]: DHCPREQUEST for 172.16.0.105 on wlan0 to 255.255.255.255 port 67
Feb 12 15:56:12 pi-powerwall dietpi-wifi-monitor.sh[92035]: DHCPACK of 172.16.0.105 from 172.16.0.1
Feb 12 15:56:12 pi-powerwall dietpi-wifi-monitor.sh[92035]: bound to 172.16.0.105 -- renewal in 3109 seconds.
Feb 12 15:56:13 pi-powerwall dietpi-wifi-monitor.sh[407]: [  OK  ] DietPi-WiFi_Monitor | Completed

Interestingly enough one of my other devices on the same WiFi network lost its connectivity as well. It is no longer reachable from either the Pi running Dietpi as well as my laptop:

dietpi@pi-powerwall:~$ ping 172.16.0.108
PING 172.16.0.108 (172.16.0.108) 56(84) bytes of data.
From 172.16.0.105 icmp_seq=1 Destination Host Unreachable
From 172.16.0.105 icmp_seq=2 Destination Host Unreachable
From 172.16.0.105 icmp_seq=3 Destination Host Unreachable
From 172.16.0.105 icmp_seq=4 Destination Host Unreachable

$ ping 172.16.0.108
Pinging 172.16.0.108 with 32 bytes of data:
Reply from 172.16.0.101: Destination host unreachable.
Reply from 172.16.0.101: Destination host unreachable.
Reply from 172.16.0.101: Destination host unreachable.
Reply from 172.16.0.101: Destination host unreachable.

Before logging out it was reachable without any troubles. As its an IoT device I had to powercycle it to get it back on the network.

It’s as if the logout from the local console triggers some sort of disruption on the WiFi network…

Joulinar · 13 February 2023 09:36

not sure how this should be possible. @MichaIng maybe you have some ideas.

MichaIng · 14 February 2023 20:25

No idea, but an interesting case . Does journalctl show anything else when you logout? And is it the same when you login and logout with the root user?

thelampcc · 17 February 2023 10:04

I’m still wondering whether these are the same WiFi issues as reported by @unixorn . Keeping the local console login open is essentially a workaround for poor WiFi performance in my case.

@MichaIng The same behaviour when doing a root login/logout. Today I noticed this in journalctl:

Feb 17 11:02:44 pi-powerwall login[306206]: pam_unix(login:session): session closed for user root
Feb 17 11:02:44 pi-powerwall systemd[1]: getty@tty1.service: Succeeded.
Feb 17 11:02:44 pi-powerwall systemd[1]: getty@tty1.service: Scheduled restart job, restart counter is at 3.
Feb 17 11:02:44 pi-powerwall systemd[1]: Stopped Getty on tty1.
Feb 17 11:02:44 pi-powerwall systemd[1]: Started Getty on tty1.
Feb 17 11:02:59 pi-powerwall dietpi-wifi-monitor.sh[407]: [ INFO ] DietPi-WiFi_Monitor | Detected wlan0 connection loss. Reconnecting...

Could it be the getty restart triggering the connection loss?

And another peculiar issue in the same area - I cannot reliably run dietpi-update from the local console. It succeeds when doing the network test but then starts failing to resolve various hosts during the update. When I leave the local console running top and do the dietpi-update from an SSH session all is fine.

I just updated to v8.14.2 but the issue has stayed. To be clear - it’s not only a logout causing issues. It’s actually the opposite. A local console login prevents issues. So even after a fresh reboot WiFi connection issues pop up within a minute. I then login on the local console and start top to prevent further issues.

Okay - I guess this is not good for diagnosing this issue further but I have to move on and build a working setup. I have just moved the Pi to a different WiFi network which is actually a router sitting behind the network it was connected to first. It’s a cheap Chinese noname router which only supports 2.4GHz WiFi. The Pi doesn’t seem to have the same issues on this network. WiFi is responsive and local logins/logouts do not change this. The other WiFi network it was connected to before is a meshed 5GHz WiFi network served by some Deco’s. I guess the Pi is having troubles with this particular network. In both cases the distance to the router is only 3 meters.

MichaIng · 19 February 2023 19:33

It shouldn’t. This service is/should not be in any way interfering with the network. However, just to check if there is any systemd service override in place:

systemctl cat getty@tty1

The only other idea I have is that some faulty login script or command is in place. So checking htop for any unexpected processes and in case /etc/profile.d, /etc/bashrd.d, ~/.bashrc, ~/.profile for any suspicious content/entry.

unixorn · 20 February 2023 04:54

I haven’t had the rPi drop off of wifi since I started dietpi-wifi-monitor.

thelampcc · 24 February 2023 10:42

And I haven’t had any major issues since switching to a different router. Have dietpi-wifi-monitor enabled which reports occassional connection loss:

Feb 20 14:20:44 pi-powerwall dietpi-wifi-monitor.sh[405]: [ INFO ] DietPi-WiFi_Monitor | Detected wlan0 connection loss. Reconnecting...
Feb 20 16:10:03 pi-powerwall dietpi-wifi-monitor.sh[405]: [ INFO ] DietPi-WiFi_Monitor | Detected wlan0 connection loss. Reconnecting...
Feb 22 13:10:46 pi-powerwall dietpi-wifi-monitor.sh[405]: [ INFO ] DietPi-WiFi_Monitor | Detected wlan0 connection loss. Reconnecting...

Haven’t found anything suspicious in any of the login scripts but did notice that /boot/dietpi/dietpi-login has the potential to run a lot of things during login. I’m still quite sure of the workaround but the question if whether it’s useful to diagnose it (the workaround) if the real issue is unknown. Apparently the WiFi on my (?) Zero 2W is kind of incompatible with the Deco 5Ghz WiFi network?

Jappe · 24 February 2023 12:41

Yes, the zero 2 w can only handle 2,4 GHz wifi.

thelampcc · 24 February 2023 13:13

Could have sworn I saw it connected to the 5GHz network. Maybe not and it was connected to 2.4GHz instead but that doesn’t change the fact that the issues are only on the Deco network.

Edit: I just realised what happened. I replaced a Pi 4 by this Zero 2W. The 4 was connected to 5GHz.