Raspberry Pi 3B+ AC WiFi unable to use 80mhz channels

[Mushoz]

Describe the bug The Raspberry Pi is unable to sync with 80mhz channels to my AC WiFi access point when I set my regulatory domain to NL. It is able to do so whenever I utilize the US domain. The NL domain does and should support 80mhz channels. More people seem to experience this issue as is evident here: https://www.raspberrypi.org/forums/viewtopic.php?t=208384

To reproduce

1. Fresh boot of Raspbian
2. Set the regulatory domain to NL via raspi-config or wpa_supplicant.conf
3. Connect to 5 Ghz WiFi

Expected behaviour Connects with 80mhz channel at 433 Mbit physical link speed

Actual behaviour Connects with 40mhz channel at 200 Mbit physical link speed

System Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW Pi3B+
• Which OS and version (cat /etc/rpi-issue)? Raspberry Pi reference 2018-11-13 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7e0c786c641ba15990b5662f092c106beed40c9f, stage4
• Which firmware version (vcgencmd version)? Feb 12 2019 19:42:42 Copyright (c) 2012 Broadcom version 8eff5e4023657a8b3b59e1f90dc966f62d74908c (clean) (release) (start)
• Which kernel version (uname -a)? Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux

[lategoodbye]

Thanks for your report, did you already tried Kernel 4.19?

[Mushoz]

I did not. I am creating a backup now. Will update to kernel 4.19 afterwards and report back.

[Mushoz]

Exact same issue on kernel 4.19 unfortunately.

[lategoodbye]

@Mushoz Could you please attach the version of the Wifi firmware ( dmesg | grep brcmfmac )?

[Mushoz]

Of course. Here is the output of said command. Please do note that I reverted my backup, so I am back to the 4.14.98 kernel as the Pi is used in production.

pi@raspberrypi:~ $ dmesg | grep brcmfmac
[    3.809580] brcmfmac: F1 signature read @0x18000000=0x15264345
[    3.817136] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
[    3.817759] usbcore: registered new interface driver brcmfmac
[    4.134409] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[    4.134965] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2018-03-09 18:56:28 
[    6.509802] brcmfmac: power management disabled

[Mushoz]

Has there been any news regarding this issue? Were you able to reproduce the issue by using the NL regulatory domain?

[Mushoz]

Any updates regarding this issue?

[Mushoz]

Any updates? This should be relatively easy to test whether it is reproducible on your end? Would love to see this fixed and utilize the full bandwidth of the Pi's WiFi.

[Mushoz]

I would really appreciate a response. If this is currently not a priority, that's fine to state also. But I am currently being completely left in the dark.

[pelwell]

This is not a priority. The channel width is almost certainly set by the regulatory information in the clm_blob, and therefore hard for us to examine and get changed.

One thought, though, having re-read the original issue: The WiFi device is connected to the SoC via an SDIO interface that is 4 bits wide and clocked at ~50MHz. Ignoring the overheads of packet headers, command traffic etc., this would give a theoretical maximum data rate of 50MHz*4bits = 200Mb/s in one direction at a time, so even if 80MHz channels were available you wouldn't be able to get more than 200Mb/s down them.

[Seketh]

The problem in this is that rx bitrate is also affected. It's usually 150Mb/s, but with Buster I'm currently experiencing even lower numbers:

Station xx:xx:xx:xx:xx:xx (on wlan0) inactive time: 0 ms rx bytes: 2674590559 rx packets: 293274058 tx bytes: 3809445833 tx packets: 177378869 tx failed: 2936 signal: -30 [-30] dBm tx bitrate: 200.0 MBit/s rx bitrate: 121.5 MBit/s authorized: yes authenticated: yes associated: yes WMM/WME: yes TDLS peer: yes DTIM period: 1 beacon interval:100 short slot time:yes connected time: 43932 seconds

My region is PT. Setting US on wpa_supplicant.conf gives us 80mhz, however, iw gets stuck on a loop fighting the AP region, meaning the connection is constantly dropping and unusable...

[pelwell]

There's now an updated clm_blob that should give access to the 80MHz channels: https://drive.google.com/file/d/1AN7lC_kMJGGg5AJLhSRtlTRgIh9qJlaI/view?usp=sharing

[Mushoz]

Awesome! Any idea when this will appear via regular updates? I am not a huge fan of running binary blobs from google drives. While it's probably okay, as you are a maintainer in this repo, I'd still prefer to wait.

[popcornmix]

It will get a regular update far sooner if people who require it are willing to test. We're not going to push it to a regular update without confirmation it fixes an issue reported.

[Mushoz]

Fair enough. I am willing to see if this fixes the issue, since that raspberry pi in question isn't doing anything mission critical. How do I load this file? Is this a firmware that will be flashed to the WiFi chip? Or can I load this as a module without making it a permanent change (in case I run into issues).?

[Mushoz]

As seen from my router. So it's definitely fixed with this blob, thank you very much! Not sure if this is the way to do it, but I simply replaced (backupped first) the same file in /lib/firmware/brcm/ and rebooted.

[pelwell]

That was the right thing to do - thanks for the feedback. If we don't hear anything negative it will hit the firmware-nonfree repo today or tomorrow, then be rolled into the next Raspberry Pi OS packages and image.

[Mushoz]

Will let you know if I run into any issues! Thanks again.

[Seketh]

I was unable to connect to channel 100, was working fine before. iw wlan0 scan | grep -A5 'freq: 5' returns nothing, can someone confirm?

Channel 36 is working and it now connects at 433.3Mbps.

[pelwell]

Which region are you in?

[Seketh]

Which region are you in?

PT

[max17048]

channel I was unable to connect to channel 100, was working fine before. iw wlan0 scan | grep -A5 'freq: 5' returns nothing, can someone confirm?

Channel 36 is working and it now connects at 433.3Mbps.

Did you change the width on channel 100? If you changed width from 80MHz to 160MHz, then you hit the Weather Radar-Channels 120..128. If there is something going on, the 5GHz-device falls back to 36..64. This is based on EU-Regulatory to protect priority (Radar)channels. As the weather-radar is on slow rotating antennas, there can be timeouts up to 25 minutes before your device recognize them and fall back. Give them a try and reduce width of channel 100 to 80MHz. Unfortunately, channel 36..64 is the only range supporting 160MHz w/o problems.

[Seketh]

channel I was unable to connect to channel 100, was working fine before. iw wlan0 scan | grep -A5 'freq: 5' returns nothing, can someone confirm? Channel 36 is working and it now connects at 433.3Mbps.

Did you change the width on channel 100? If you changed width from 80MHz to 160MHz, then you hit the Weather Radar-Channels 120..128. If there is something going on, the 5GHz-device falls back to 36..64. This is based on EU-Regulatory to protect priority (Radar)channels. As the weather-radar is on slow rotating antennas, there can be timeouts up to 25 minutes before your device recognize them and fall back. Give them a try and reduce width of channel 100 to 80MHz. Unfortunately, channel 36..64 is the only range supporting 160MHz w/o problems.

Sorry for the late reply!

So it seems I had another issue, my 3A+ for some reason was not reconnecting after changing the channel (not even to 2.4GHz, I have the same SSID, using band steering). Did a clean install and apparently it is working now.

I also just now tested with a Pi 4 and it is working, both channel 36 and 100.

[pelwell]

That's good news - the new blob is now in the firmware-brcm80211 package, and the latest RPiOS image.