RPi Wifi stops working after reboot but works again after a proper shutdown

Ravi · 27 March 2023 22:20

Required Information

DietPi version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=15
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘not applicable’
Distro version
bullseye 1
Kernel version
Linux DietPi 6.1.19+ #1637 Tue Mar 14 11:01:56 GMT 2023 armv6l GNU/Linux
SBC model
RPi B (armv6l)
Power supply used | (EG: 5V 1A RAVpower)
Generic 5V 1A
SD card used
Toshiba SD - K16G (16Gigs)

Steps to reproduce

Turn on DietPi and Wi-Fi is connected. Reboot the Pi and after boot up, Wi-Fi will not connect to modem/router (the only one in the apartment) for some reason.
Perform a clean shutdown from the terminal (after connecting keyboard) and booting up again solves the issue. Wi-Fi is up again!

Expected behaviour

Wi-Fi should be up whether it’s from a restart or shutdown.

Actual behaviour

Wi-Fi will connect back only after a clean shutdown.

Extra details

Yes!

Logs after reboot:

ifup wlan0

root@DietPi:/home/dietpi# ifup_wlan0 
ifup: interface wlan0 already configured
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/wlan0/00:19:86:11:93:37
Sending on   LPF/wlan0/00:19:86:11:93:37
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

dietpi-wifi-monitor

root@DietPi:/home/dietpi# systemctl status dietpi_wifi_monitor 
● dietpi-wifi-monitor.service - DietPi-WiFi_Monitor
     Loaded: loaded (/etc/systemd/system/dietpi-wifi-monitor.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-03-27 14:28:54 PDT; 2min 25s ago
   Main PID: 478 (dietpi-wifi-mon)
      Tasks: 9 (limit: 876)
        CPU: 4.821s
     CGroup: /system.slice/dietpi-wifi-monitor.service
             ├─478 /bin/bash /var/lib/dietpi/services/dietpi-wifi-monitor.sh
             ├─863 ifup wlan0
             ├─876 /sbin/wpa_supplicant -s -B -P /run/wpa_supplicant.wlan0.pid -i wlan0 -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplicant.conf
             ├─880 /bin/sh -c CLIENT="-i";  /sbin/dhclient -4 -v $CLIENT -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases -I -df /var/lib/dhcp/dhclient6.wlan0.leases wlan0
             ├─881 /sbin/dhclient -4 -v -i -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases -I -df /var/lib/dhcp/dhclient6.wlan0.leases wlan0
             └─882 /sbin/dhclient -4 -v -i -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases -I -df /var/lib/dhcp/dhclient6.wlan0.leases wlan0

Mar 27 14:30:46 DietPi wpa_supplicant[876]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="XXXXXXXX" auth_failures=2 duration=20 reason=CONN_FAILED
Mar 27 14:30:54 DietPi dhclient[882]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
Mar 27 14:30:54 DietPi dietpi-wifi-monitor.sh[882]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
Mar 27 14:31:01 DietPi dhclient[882]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
Mar 27 14:31:01 DietPi dietpi-wifi-monitor.sh[882]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
Mar 27 14:31:07 DietPi wpa_supplicant[876]: wlan0: CTRL-EVENT-SSID-REENABLED id=0 ssid="XXXXXXX"
Mar 27 14:31:07 DietPi wpa_supplicant[876]: wlan0: SME: Trying to authenticate with d4:86:60:ae:b5:1d (SSID='XXXXXXX' freq=2412 MHz)
Mar 27 14:31:08 DietPi wpa_supplicant[876]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="XXXXXXXX" auth_failures=3 duration=30 reason=CONN_FAILED
Mar 27 14:31:10 DietPi dhclient[882]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
Mar 27 14:31:10 DietPi dietpi-wifi-monitor.sh[882]: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15

lsusb:

root@DietPi:/home/dietpi# lsusb 
Bus 001 Device 005: ID 0bda:818b Realtek Semiconductor Corp. RTL8192EU 802.11b/g/n WLAN Adapter
Bus 001 Device 004: ID 045e:07b2 Microsoft Corp. 2.4GHz Transceiver v8.0 used by mouse Wireless Desktop 900
Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

RTL8192EU Driver:

root@DietPi:/home/dietpi# dmesg -T | grep -i rtl 
[Thu Mar 23 11:34:30 2023] usb 1-1.3: rtl8192eu_parse_efuse: dumping efuse (0x200 bytes):
[Thu Mar 23 11:34:30 2023] usb 1-1.3: RTL8192EU rev D (SMIC) 2T2R, TX queues 3, WiFi=1, BT=0, GPS=0, HI PA=0
[Thu Mar 23 11:34:30 2023] usb 1-1.3: RTL8192EU MAC: 00:19:86:11:93:37
[Thu Mar 23 11:34:30 2023] usb 1-1.3: rtl8xxxu: Loading firmware rtlwifi/rtl8192eu_nic.bin
[Thu Mar 23 11:34:31 2023] usbcore: registered new interface driver rtl8xxxu

interfaces:

root@DietPi:/home/dietpi# cat /etc/network/interfaces 
# Location: /etc/network/interfaces
# Please modify network settings via: dietpi-config
# Or create your own drop-ins in: /etc/network/interfaces.d/

# Drop-in configs
source interfaces.d/*

# Ethernet
allow-hotplug eth0
iface eth0 inet dhcp
#gateway .1
#dns-nameservers 

# WiFi
allow-hotplug wlan0
iface wlan0 inet dhcp
#gateway .1
#dns-nameservers 
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

I haven’t included wpa-supplicant as I know the problem does not lie there. Also, I only performed an ifup after doing an ifdown. I’m not a network wizard, but it seems to me that the Pi is unable to re-register its MAC address with the AP and therefore the connection fails. But I cannot understand why it’s able to do it after a clean shutdown

Thanks a lot for your input guys! Much appreciated

Joulinar · 28 March 2023 08:04

what WiFi channel you are using on your local network?

Ravi · 28 March 2023 21:38

Hey Joulinar,

Thanks for getting back to me. Here is the output from iwlist:

root@DietPi:~# iwlist wlan0 scan | grep -i -B5 telus
          Cell 12 - Address: D4:86:60:AE:B5:1D
                    Channel:11
                    Frequency:2.462 GHz (Channel 11)
                    Quality=70/70  Signal level=-34 dBm  
                    Encryption key:on
                    ESSID:"TELUSXX"

The network has both 5GHz and 2.4 GHz:

Network_channels

Thank you!

Joulinar · 29 March 2023 06:53

are you sure wifi password is correct? And just for testing, would it be possible to lower the wifi channel to 6?

Ravi · 30 March 2023 19:21

Hey Joulinar,

Yes I am absolutely certain that the password is correct as it connects to the Wi-Fi after a clean shutdown, but here it is anyway:

# Grant all members of group "netdev" permissions to configure WiFi, e.g. via wpa_cli or wpa_gui
ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev
# Allow wpa_cli/wpa_gui to overwrite this config file
update_config=1
network={
	ssid="TELUSXXX"
	key_mgmt=WPA-PSK
	psk=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
}

I changed Wi-Fi channel on the AP to 6 and the Pi successfully connects to it, but after a reboot the same problem arises:

root@DietPi:~# iwlist wlan0 scan | grep -i -B5 telus98ea
          Cell 06 - Address: D4:86:60:AE:B5:1D
                    Channel:6
                    Frequency:2.437 GHz (Channel 6)
                    Quality=64/70  Signal level=-46 dBm  
                    Encryption key:on
                    ESSID:"TELUSXX"

I’m at a loss to explain this!

Cheers,
Ravi

Joulinar · 30 March 2023 21:40

maybe @MichaIng could have a look.

MichaIng · 30 March 2023 21:51

Can you show the output of:

iw reg get

Ravi · 31 March 2023 01:41

Sure MichaIng,

Here it is:

root@DietPi:~# iw reg get
global
country 00: DFS-UNSET
	(755 - 928 @ 2), (N/A, 20), (N/A), PASSIVE-SCAN
	(2402 - 2472 @ 40), (N/A, 20), (N/A)
	(2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
	(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
	(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
	(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
	(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
	(5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
	(57240 - 63720 @ 2160), (N/A, 0), (N/A)

How do we interpret this output? Thanks a lot by the way guys!

Cheers

MichaIng · 31 March 2023 13:30

So indeed no country code is distributed by the access point. Can you test this:

iw reg set GB
sleep 1
iw reg get

Replace GB (Great Britain) with the country code you are located. If it shows country 99, try again this way:

ifdown wlan0
iw reg set GB
ifup wlan0
sleep 1
iw reg get

Ravi · 31 March 2023 21:04

Hey MichalIng,

I tested the commands you gave me:

root@DietPi:~# iw reg set CA
root@DietPi:~# iw reg get
global
country CA: DFS-FCC
	(2402 - 2472 @ 40), (N/A, 30), (N/A)
	(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
	(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
	(5470 - 5600 @ 80), (N/A, 24), (0 ms), DFS
	(5650 - 5730 @ 80), (N/A, 24), (0 ms), DFS
	(5735 - 5835 @ 80), (N/A, 30), (N/A)

root@DietPi:~#

It lost it after reboot, but that’s to be expected since it is not hard set somewhere!

Thanks again,
Ravi

queeup · 1 April 2023 18:49

I have exact same problem with raspberry pi zero w. After fresh install, first setup is updating and rebooting my pi. And I am losing my wifi connection.

My workaround is in first boot login with ssh as a user and add country=XX to /etc/wpa_supplicant/wpa_supplicant.conf and then logout and login as root to continue first boot.

Probably this problem starts after crda package removed on update for sake of new kernel handling wifi regulation…

Joulinar · 1 April 2023 19:02

Usually country code should be distributed by the access points. But some this is not the case always we are looking on how to work around.

MichaIng · 3 April 2023 20:22

@Ravi
And doing this fixes your WiFi (until you reboot)?

Hah, there IS a way via wpa_supplicant. I was actually looking for this but couldn’t find it on any man page:

Did you apply this outside of the network blocks at the top of the file?

After not finding the setting, I found it actually logic as it may not even come to WPA authentication if the WiFi channel/frequency does not match. But seems that wpa_supplicant does this somehow earlier or that WPA is not affected by the frequency or so.

That is great so there is a common way to apply the country code on Bookworm to overcome these issues. I was already wondering.

queeup · 3 April 2023 21:59

Did you apply this outside of the network blocks at the top of the file?

Yes. Just before network

MichaIng · 7 April 2023 13:47

Solved with: v8.16 · MichaIng/DietPi@8c4fa63 · GitHub