Wifi lost after dist-upgrade on rpi4B rev 1.5

Question

Wifi lost after dist-upgrade on rpi4B rev 1.5

rkarlsba opened this issue 3 years ago · 47 comments

I just got this rpi4 2GB rev 1.5 and it works well, or did, until I did a dist-upgrade and it lost contact with wifi altogether. It seems it's a driver issue - I can't even iwlist wlan0 scan or up the nic. I tried to upgrade firmware, but it didn't help anything. I've tried to reinstall several times (since it's not in use yet) and have reproduced the error all of those times. It goes like this (the fourth, the fift):

Put 2022-01-28-raspios-bullseye-arm64-lite.img on an sd card.
Touch /boot/ssh and setup /boot/wpa_supplicant.conf, add enable_uart=1 to config.txt (the latter only for debugging, it reproduces well without it, but I don't have anything with hdmi here).
Boot the OS, set new password.
Check networking - it all works (only tested on 2.4GHz - 5GHz didn't seem to work). I got valid IPv4 and IPv6 addresses.
run 'apt update && apt full-upgrade'
(the minor flaw)
Reboot
(and the major lift)
And check network settings. Nothing on the wifi. NIC is down.
(The baffled king composing Hallelujah)

The firmware was a tad old, so I upgraded to the latest firmware from Thu 10 Mar 2022 11:57:12 AM UTC and it didn't help anything.

PS: There's a line in dmesg that might be relevant, but I'm not sure: cfg80211: loaded regulatory.db is malformed or signature is missing/invalid

Answer 1 · 2022-03-31T08:03:49.000Z

[ 28.364825] ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=4108, -52
uname -r
5.15.30-v7l+

This also happens at 32bit.
No SSID releases.

Answer 2 · 2022-03-31T08:39:18.000Z

Starting with a clean download of the 64-bit RPi-OS and running sudo apt update && sudo apt full-upgrade didn't cause any problems on a rev 1.2 Pi 4B.

Can anyone experiencing this issue post:

the initial OS version - 32 vs 64, Lite vs Normal vs Full, image date if known,
the upgrade method - dist-upgdate, full-upgrade,
the output of tail /proc/cpuinfo,
the whole of dmesg shortly after boot,
the WLAN channel and country code (as @ghollingworth asks)?

Answer 3 · 2022-03-31T08:41:56.000Z

Also what channel/country are you selecting?

Answer 4 · 2022-03-31T08:52:04.000Z

Starting with a clean download of the 64-bit RPi-OS and running sudo apt update && sudo apt full-upgrade didn't cause any problems on a rev 1.2 Pi 4B.

It does on rev 1.5

Can anyone experiencing this issue post:
1. the initial OS version - 32 vs 64, Lite vs Normal vs Full, image date if known,

Last I checked, the kernel is the same for all of these, and I used 2022-01-28-raspios-bullseye-arm64-lite.img and as yutayu says, it's the same on 32bit.

2. the upgrade method - `dist-upgdate`, `full-upgrade`,

If you look at the code, dist-upgrade is just an alias for full-upgrade. And I have tried them both - same result.

3. the output of `tail /proc/cpuinfo`,

I guess you're looking for these

Hardware : BCM2835
Revision : b03115
Serial : 100000004dc89f36
Model : Raspberry Pi 4 Model B Rev 1.5

4. the whole of `dmesg` shortly after boot?

https://paste.debian.net/1236251/

Answer 5 · 2022-03-31T08:52:59.000Z

Also what channel/country are you selecting?

It was set to NO, since I'm in Norway, and that has worked well on other pis. I've tried SE and UK as well with the same result.

Answer 6 · 2022-03-31T08:54:33.000Z

Also what channel/country are you selecting?

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=NO

network={
        ssid="mynet"
        psk="mypw"
}

Answer 7 · 2022-03-31T09:00:28.000Z

There is nothing obviously wrong in your kernel log. How about iwlist channel and iwconfig?

Answer 8 · 2022-03-31T09:01:24.000Z

root@raspberrypi:~# iwlist channel
lo        no frequency information.

eth0      no frequency information.

wlan0     32 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Channel 12 : 2.467 GHz
          Channel 13 : 2.472 GHz
          Channel 14 : 2.484 GHz
          Channel 34 : 5.17 GHz
          Channel 36 : 5.18 GHz
          Channel 38 : 5.19 GHz
          Channel 40 : 5.2 GHz
          Channel 42 : 5.21 GHz
          Channel 44 : 5.22 GHz
          Channel 46 : 5.23 GHz
          Channel 48 : 5.24 GHz
          Channel 52 : 5.26 GHz
          Channel 56 : 5.28 GHz
          Channel 60 : 5.3 GHz
          Channel 64 : 5.32 GHz
          Channel 100 : 5.5 GHz
          Channel 104 : 5.52 GHz
          Channel 108 : 5.54 GHz
          Channel 112 : 5.56 GHz
          Channel 116 : 5.58 GHz
          Channel 120 : 5.6 GHz
root@raspberrypi:~# iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wlan0     IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on

root@raspberrypi:~#

Answer 9 · 2022-03-31T09:01:48.000Z

root@raspberrypi:~# 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: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether e4:5f:01:9e:fd:83 brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether e4:5f:01:9e:fd:84 brd ff:ff:ff:ff:ff:ff
root@raspberrypi:~#

Answer 10 · 2022-03-31T09:05:44.000Z

the initial OS version - 32 vs 64, Lite vs Normal vs Full, image date if known,
32bit,Normal,1-28
uname -a
Linux raspberrypi 5.15.30-v7l+ #1536 SMP Mon Mar 28 13:51:42 BST 2022 armv7l GNU/Linux

the upgrade method - dist-upgdate, full-upgrade,
full-upgrade

the output of tail /proc/cpuinfo,
tail /proc/cpuinfo
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3

Hardware : BCM2711
Revision : c03112
Serial : 10000000c2ebe06a
Model : Raspberry Pi 4 Model B Rev 1.2

the whole of dmesg shortly after boot,
log.txt

the WLAN channel and country code (as @ghollingworth asks)?
13
JP

Answer 11 · 2022-03-31T09:30:45.000Z

It's also working on a rev 1.4 (I haven't located a 1.5 yet, but honestly there should be no difference in this regard) 32-bit system set to NO. It connects to 2.4 and 5 bands.

Answer 12 · 2022-03-31T09:47:15.000Z

Mar 31 18:42:53 raspberrypi hostapd[6840]: Configuration file: /etc/hostapd/hostapd.conf
Mar 31 18:42:53 raspberrypi hostapd[6840]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Mar 31 18:42:53 raspberrypi hostapd[6840]: Using interface wlan0 with hwaddr dc:a6:32:89:fb:be and ssid >
Mar 31 18:42:53 raspberrypi kernel: ieee80211 phy0: brcmf_cfg80211_start_ap: Set Channel failed: chspec=>
Mar 31 18:42:53 raspberrypi hostapd[6840]: Failed to set beacon parameters
Mar 31 18:42:53 raspberrypi hostapd[6840]: wlan0: Could not connect to kernel driver
Mar 31 18:42:53 raspberrypi hostapd[6840]: Interface initialization failed
Mar 31 18:42:53 raspberrypi hostapd[6840]: wlan0: interface state COUNTRY_UPDATE->DISABLED
Mar 31 18:42:53 raspberrypi hostapd[6840]: wlan0: AP-DISABLED
Mar 31 18:42:53 raspberrypi hostapd[6840]: wlan0: Unable to setup interface.
Mar 31 18:42:53 raspberrypi hostapd[6840]: wlan0: interface state DISABLED->DISABLED
Mar 31 18:42:53 raspberrypi hostapd[6840]: wlan0: AP-DISABLED
Mar 31 18:42:53 raspberrypi hostapd[6840]: wlan0: CTRL-EVENT-TERMINATING
Mar 31 18:42:53 raspberrypi hostapd[6840]: hostapd_free_hapd_data: Interface wlan0 wasn't started
Mar 31 18:42:53 raspberrypi hostapd[6840]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Mar 31 18:42:53 raspberrypi sudo[6836]: pam_unix(sudo:session): session closed for user root
Mar 31 18:42:53 raspberrypi systemd[1]: hostapd.service: Control process exited, code=exited, status=1/F>

Answer 13 · 2022-03-31T09:54:47.000Z

Installing and enabling hostapd is a non-standard configuration and should always be mentioned in bug reports. However, I think @rkarlsba is not using hostapd - am I right?

Answer 14 · 2022-03-31T10:02:25.000Z

I changed wifi channel 13 to 11 and it works.

Answer 15 · 2022-03-31T10:15:21.000Z

@rkarlsba As part of the investigation, what is your current WLAN channel and (if you can) does changing it help?

Answer 16 · 2022-03-31T12:11:02.000Z

To see if this failure is as the result of the kernel change, you can revert to a 5.10 kernel with sudo rpi-update 770ca2c2.

Answer 17 · 2022-03-31T12:35:44.000Z

@pelwell It was at channel 12. I moved it to channel 10 and now it works. Thanks :)

I'm using openwrt, meaning hostapd, it seems

Answer 18 · 2022-03-31T12:46:48.000Z

And yes, I can confirm that rolling back to 5.10 "fixes" this.

Answer 19 · 2022-03-31T12:53:50.000Z

Thanks - that should be enough to work on for now.

Answer 20 · 2022-03-31T12:55:49.000Z

oh - btw - no errors in the kernel log about regulatory.db in 5.10

Answer 21 · 2022-03-31T12:58:09.000Z

5.15 gave me these

Mar 29 18:43:01 pi kernel: [ 5.119194] cfg80211: Loading compiled-in X.509 certificates for regulatory database
Mar 29 18:43:01 pi kernel: [ 5.154400] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid

Answer 22 · 2022-03-31T13:16:10.000Z

I can reproduce the issue here - the 5.15 kernel seems to be restricting WiFi to the lowest common denominator of channels 1-11.

Answer 23 · 2022-03-31T13:17:59.000Z

…which looks like a bad regulatory.db ;)

Answer 24 · 2022-03-31T13:21:02.000Z

Yes, probably, but in my experiences it's better not to jump to conclusions.

Answer 25 · 2022-03-31T13:22:36.000Z

I was guessing, not concluding ;)

Answer 26 · 2022-03-31T13:26:26.000Z

Would you care to guess what the solution is?

Answer 27 · 2022-03-31T13:28:13.000Z

Replace regulatory.db with a valid file, one that 5.15 can accept

Answer 28 · 2022-03-31T13:42:44.000Z

FWIW, I'm seeing the loaded regulatory.db is malformed or signature is missing/invalid message on 5.10 as well on my pi400, running pios arm64. Might be a red herring.

Answer 29 · 2022-03-31T13:47:22.000Z

Perhaps 5.15 is enforcing that? dunno

Answer 30 · 2022-03-31T14:01:51.000Z

Updating to the latest regulatory.db removes the error message but doesn't solve the problem:

Download https://mirrors.edge.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2022.02.18.tar.xz
Extract regulatory.db and regulatory.db.p7s.
Copy them to /lib/firmware/.
Reboot.

Answer 31 · 2022-03-31T14:16:13.000Z

Confirmed - doesn't help

Answer 32 · 2022-03-31T17:17:19.000Z

I've traced the problem to a downstream commit that got replaced by an upstream commit (yay), which was then reverted by another upstream commit (boo). The absence of the commit causes the driver to silently (unless you turn on super verbose brcmfmac tracing) fail to configure the country codes in the WLAN chip, making it default to a worldwide-safe mode.

raspberrypi/linux@6f921e9 is the replacement patch.

Answer 33 · 2022-03-31T17:20:25.000Z

Thanks a bunch. Is this in the repos yet?

Answer 34 · 2022-03-31T17:21:38.000Z

Only the source repo - the rest will take a bit longer.

Answer 35 · 2022-03-31T17:24:27.000Z

what is 'a bit'?

Answer 36 · 2022-03-31T17:26:43.000Z

It's an English phrase which, in this context, means a short interval of time.

Answer 37 · 2022-03-31T17:28:09.000Z

It's an English phrase which, in this context, means a short interval of time.

I know what it means, but I also know that "a short interval of time" is quite relative ;)

Answer 38 · 2022-03-31T17:33:49.000Z

Dad! How far away is Mars?
Only five minutes or so, why?
Cool, let's walk!

Answer 39 · 2022-03-31T18:45:50.000Z

Available from rpi-update now.

Answer 40 · 2022-04-01T02:46:38.000Z

Thanks - works well :)

Answer 41 · 2022-04-01T05:50:17.000Z

Is this fed to the apt repos yet?

Answer 42 · 2022-04-01T20:17:19.000Z

The apt package update should be live now.

Answer 43 · 2022-04-01T20:19:38.000Z

Thank you - and have a nice weekend :)

Answer 44 · 2022-04-12T01:58:26.000Z

Forgive me for commenting on a closed issue, but I think that I'm affected by this same issue, but my hardware is different. I'll open a new issue if that's required.

I have the same message cfg80211: loaded regulatory.db is malformed or signature is missing/invalid in my logs. My symptom is that I cannot access any channel above 11.

Running the latest OS:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye

My country code is Australia, which took some extra doing, forcing it in two places, /etc/modprobe.d/cfg80211.conf and /etc/default/crda :

# iw reg get 
global
country AU: DFS-ETSI
	(2400 - 2483 @ 40), (N/A, 36), (N/A)
	(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
	(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
	(5470 - 5600 @ 80), (N/A, 27), (0 ms), DFS
	(5650 - 5730 @ 80), (N/A, 27), (0 ms), DFS
	(5730 - 5850 @ 80), (N/A, 36), (N/A)
	(57000 - 66000 @ 2160), (N/A, 43), (N/A), NO-OUTDOOR

I can only see the first 11 2.4 GHz channels:

# iwlist chan
lo        no frequency information.

eth0      no frequency information.

wlan0     11 channels in total; available frequencies :
          Channel 01 : 2.412 GHz
          Channel 02 : 2.417 GHz
          Channel 03 : 2.422 GHz
          Channel 04 : 2.427 GHz
          Channel 05 : 2.432 GHz
          Channel 06 : 2.437 GHz
          Channel 07 : 2.442 GHz
          Channel 08 : 2.447 GHz
          Channel 09 : 2.452 GHz
          Channel 10 : 2.457 GHz
          Channel 11 : 2.462 GHz
          Current Frequency:2.412 GHz (Channel 1)

docker0   no frequency information.

After attempting to update using the normal apt update && apt -y upgrade, I finally updated with rpi-update, which didn't fix the issue (the output below is the second run, the first run updated the firmware and kernel modules.

# rpi-update 
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Your firmware is already up to date (delete /boot/.firmware_revision to force an update anyway)

I'm running this hardware:

# awk '/^Revision/ {sub("^1000", "", $3); print $3}' /proc/cpuinfo
a21041

Which according to perturb.org/rpi?rev=a21041 is this:

Revision: a21041
Model: 2 Model B
Memory: 1 GB
Overvolt: No
Release: Q1 2015
Notes: (Mfg by Embest)

The Wireless Hardware is:

# lsusb -vd 0bda:8179

Bus 001 Device 005: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0x8179 RTL8188EUS 802.11n Wireless Network Adapter
  bcdDevice            0.00
  iManufacturer           1 Realtek
  iProduct                2 802.11n NIC
  iSerial                 3 00E04C0001
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0002
  (Bus Powered)
  Remote Wakeup Enabled

I also tried forcing the reinstallation of the firmware: apt --reinstall install firmware-brcm80211

No doubt I'm missing something obvious, but my 23 years using debian hasn't been able to help this time ;-(

Answer 45 · 2022-04-12T07:25:18.000Z

The Wireless Hardware is: Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
...
I also tried forcing the reinstallation of the firmware: apt --reinstall install firmware-brcm80211

AFAIK brcm80211 is for Broadcom Wifi hardware, so I see no reason to think why it would help get a Realtek Wifi dongle working? 😉

As your issue is regarding different wireless hardware to what this issue was originally about, this sounds like a separate problem, so I think your best course of action is to open a new issue at https://github.com/raspberrypi/linux/issues
(and you probably ought to mention if you've ever had this Wifi dongle working with the Raspberry Pi, or if this is a new problem)

Answer 46 · 2022-04-12T07:56:41.000Z

Forgive me, I took the root cause to be a corruption of the regulatory.db, not the underlying driver and (mis-)understood the fix to be a patch that dealt with that. This hardware has previously worked, but stopped working when my network changed to channel 13, something which I only discovered when I reconnected a screen and keyboard to my headless pi.

I'm happy to create a new issue, but as I said, I thought this ticket was about the regulatory.db being corrupt.

Answer 47 · 2022-04-12T10:43:35.000Z

The fix for this issue was in the file drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c, so the bug and fix were brcm80211 specific. Create a new issue for a bug with some other hardware.