Wifi Drops out after update to 8.14.2

Troubleshooting
21

Hi,
I’m not sure if it’s related, but after I’ve updated my RPI 4B to 8.14.2 yesterday, it’s not able to connect to 2.4 bands anymore. Whereas 5G works fine.

I’ve got several accesspoits (repeater) and one of those is only capable of 2.4G (from the original location of the RPi only this AP is reachable). So when I move the device to a place where it can connect to a 5G AP, everything seems to work fine (it connects to 5G). When moving back to original location, no connection possible.

Before the update it was working absolutly fine (it was up for almost a year without noticing any issues.

I tried to do some research, but didn’t get much further yet. The only hint I got so far is that it might have something to do with this. From the dietpi changelog I can also see some hint regarding removal of Central Regulatory Domain Agent (CRDA). If I recall correctly, there was also some dialog poping up during the update process which asked to remove that, which I confirmed.

Do you thing, it might be related?

22

we had a report where the WiFi channel matters. What channel you are using on 2.4 ?

23

Same here +

I upgraded one of my Pi 400s yesterday, and after the reboot got hit with wifi issues (plus curiously, the Ethernet connection as well), played around and it worked once last night, switching on today not.

Odd. Didn’t see much in the kernel buffer or journal.

I’ll investigate later but if I recall the apt upgrade changed about 280 files, etc. and I wonder what could be broken?

(I tried the eee off trick last night and had hoped that would have fixed it, seemingly not.]

[I’ll add the wifi monitor manually later too.]

Update: What I should have said was:

  1. Did the 8.14.2 a few days ago
  2. Yesterday did my usual apt update/upgrade and then got hit
  3. I did take the CRDA remove option.
  4. Am curious as to why the eth0 wouldn’t pick up an address (is plugged straight into a local desktop, as a failback (changed cable etc but will double check)) Might well have been a cable issue (too many for my own good!!), but even when that was fixed (I could verify by pulling cable and watch dmesg for Link down/up messages) it didn’t go and grab an ip address, so I did it manually and now seems ok.
  5. Running Dietpi-config again and doing a scan worked, Wlan0 has an ip address, will need to watch next reboot.
    Update 3:
  6. My results are:

6.1 ls -l /etc/alternatives/regulatory.db
lrwxrwxrwx 1 root root 36 Feb 13 20:36 /etc/alternatives/regulatory.db → /lib/firmware/regulatory.db-upstream
root@easca:~#

6.2 dmesg shows no error about loading the regulatory database?

6.3 iw reg get shows:

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

phy#0
country 99: DFS-UNSET
(2402 - 2482 @ 40), (6, 20), (N/A)
(2474 - 2494 @ 20), (6, 20), (N/A)
(5140 - 5360 @ 160), (6, 20), (N/A)
(5460 - 5860 @ 160), (6, 20), (N/A)

What should one expect for Britain here?

Update 4:

  1. Answering my own question by comparing with Raspberry Pi OS (on another test setup Pi 400) and it shows:

iw reg get
global
country GB: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (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 - 5730 @ 160), (N/A, 26), (0 ms), DFS
(5725 - 5850 @ 80), (N/A, 23), (N/A), NO-OUTDOOR
(57000 - 71000 @ 2160), (N/A, 40), (N/A)

phy#0
country 99: DFS-UNSET
(2402 - 2482 @ 40), (6, 20), (N/A)
(2474 - 2494 @ 20), (6, 20), (N/A)
(5140 - 5360 @ 160), (6, 20), (N/A)
(5460 - 5860 @ 160), (6, 20), (N/A)

Therefore my next test would seem to be a plain reboot (on the Pi 400 with Diet Pi, check again and maybe use iw reg to set the country code if there are issues.

8.0 Reboot resulted in no wlan0 address, afterwards set it, via iw reg set GB then a reboot, got an wlan0 address, just rebooting for last time to check. That worked.

[And my apologies I seem to be on Diet Pi Bookworm on my Spanish Pi 400 (probably for some very good reason if I could but recall it!), which explains the mountain of updates (another 19 just now after 280 last night, lovely lovely Debian :grin: ) ]

Thank you @MichaIng for the helpful suggestions!

1 Like
24

Everyone with WiFi issues since DietPi v8.14:

  • Since the CRDA removal was an optional choice offered during update, did you actually remove it?
  • Can you verify that ls -l /etc/alternatives/regulatory.db points to /lib/firmware/regulatory.db-upstream instead of /lib/firmware/regulatory.db-debian?
  • Does dmesg | grep cfg80211 show any error about loading the regulatory database?
  • Does iw reg get show the correct country code and expected channges/frequencies?
  • Does it help if you apt install crda and reboot?
1 Like
25

Many thanks for your tests Brian,

Did I understand it right that you need to manually run iw reg set GB to successfully connect and get an IP?

Do I understand it right that after that, even after reboot, it works? That is strange since iw reg set GB should be temporarily only and lost after reboot.

Generally, the country code should be obtained from the WiFi access point when connecting, so e.g. even if you set e.g. iw reg set DE (while not connected) and then connect, iw reg get should show GB (in Great Britain). And the kernel should be able to obtain the frequencies/channels related to the country code by itself, which is the actual change that made CRDA obsolete.

I should have also asked whether dmesg | grep cfg80211 shoes that the regulatory database was (successfully) queried. On my RPi Zero W it shows:

# dmesg | grep cfg80211
[   14.534511] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[   14.923785] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   17.682176] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
1 Like
26

Hmm, OK :grinning:

  1. Yes, @MichaIng Micha, it succeeded to get the Wlan0 address twice

But just looked at it now and I can see:

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)

phy#0
country 99: DFS-UNSET
(2402 - 2482 @ 40), (6, 20), (N/A)
(2474 - 2494 @ 20), (6, 20), (N/A)
(5140 - 5360 @ 160), (6, 20), (N/A)
(5460 - 5860 @ 160), (6, 20), (N/A)

  1. Apparently the reg. DB loads ok I can see:

[Sat Mar 11 18:44:51 2023] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[Sat Mar 11 18:44:51 2023] cfg80211: Loaded X.509 cert ‘sforshee: 00b28ddf47aef9cea7’
[Sat Mar 11 18:44:53 2023] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled

Mystified, I shall put this down to 1) not plugging in the right ethernet cable 2) Debian testing changes, but will watch it in the future.

[I finally remembered why I set this Pi 400 up as Bookworm: to get Python 3.11 for my tests with thonny.]

1 Like
27

Okay, so to me it seems that not all WiFi APs are actually passing a country code, or not all of them in a way that it is also applied by the kernel. It seems to be not hardware/kernel-specific, since it works fine with my RPi Zero W (same kernel) and other SBCs I have here with very different kernel builds and versions.

CRDA helps then, not because it is needed by the kernel to associate the two digits country code with actual channels/frequencies , but because it calls iw reg set as well via udev rule. If someone with this issue finds time to test it with a Bookworm image, just to rule out another difference I missed between Bullseye and Bookworm in this regards, that would be great.

On Bookworm, there is no CRDA package. So if you suffer from the same issue there, this would be good to report to Debian directly, as it would make sense to come up with an additional solution to apply a country code, if the AP does not pass one. This wouldn’t be so hard: The udev rule from CRDA which calls iw reg set could be copied.

Sadly it is too close now to change something for DietPi v8.15. With all needed information, we can either push a live patch or a MOTD to a solution. Would likely be an optional package hosted on our server, which ships either a udev rule.

28

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

3 Likes