Unreliable 802.11ac connection on our raspi images
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
linux-firmware (Ubuntu) |
Undecided
|
Unassigned | ||||
Bionic |
Undecided
|
Unassigned | ||||
Eoan |
Undecided
|
Unassigned | ||||
Focal |
Undecided
|
Unassigned | ||||
linux-firmware-raspi2 (Ubuntu) |
Undecided
|
Unassigned | ||||
Bionic |
Undecided
|
Unassigned | ||||
Eoan |
Undecided
|
Unassigned | ||||
Focal |
Undecided
|
Unassigned | ||||
linux-raspi (Ubuntu) |
Undecided
|
Unassigned | ||||
Focal |
Undecided
|
Unassigned | ||||
linux-raspi2 (Ubuntu) |
Undecided
|
Unassigned | ||||
linux-raspi2-5.3 (Ubuntu) | ||||||
Bionic |
Undecided
|
Unassigned | ||||
Eoan |
Undecided
|
Unassigned | ||||
netplan.io (Ubuntu) |
Undecided
|
Unassigned | ||||
Bionic |
Undecided
|
Unassigned | ||||
Eoan |
Undecided
|
Unassigned | ||||
Focal |
Undecided
|
Unassigned |
Bug Description
We were not able to completely pin-point the issue yet, so this is more of a blanket bug for the current issues we are seeing. We don't know where exactly the issue can be located.
While preparing and testing 18.04.4, certification reported issues with our uc18 images on the pi4 with wifi ac tests. One of our engineers (Brian) confirmed it locally with a wifi access point restricted only to 802.11ac. After some additional testing, he noticed that he had the same unreliable symptoms for both the classic and core images, as well as the 19.10.1 classic images. The symptoms seem to vary, from inability to detect 802.11ac APs, inability to connect and/or receive an IP address and no traffic getting through.
We will provide all the information that we have. Raspbian works better in this regard. We have pulled in the wifi firmware bits from Raspbian and using those, and that seems to resolve all flakiness.
Changed in linux-raspi2-5.3 (Ubuntu): | |
status: | Confirmed → New |
Brian Murray (brian-murray) wrote : | #1 |
tags: | added: bionic eoan focal rls-ff-incoming |
tags: | removed: rls-ff-incoming |
description: | updated |
Juerg Haefliger (juergh) wrote : | #2 |
Is this a problem with the Pi 4 only or across the whole fleet?
Dave Jones (waveform) wrote : | #3 |
@juergh given the Pi 3A+, 3B+, and 4B share the same wifi chipset (but not the 3B) I'd expect similar behaviour across those three models, if indeed the firmware is the issue.
Brian Murray (brian-murray) wrote : | #4 |
The only other Pi that I currently have is a 3B which does not have 802.11ac capabilities.
Dave Jones (waveform) wrote : | #5 |
A package with the latest firmware is available from the following PPA:
https:/
I've now tested this booting and operating wifi on a 3B+ and a 4B against "classic" 2.4GHz wifi, and 5GHz wifi but only 802.11n (as that's all I've got locally). Would be grateful if others could try installing this and see if 802.11ac is any better.
The proposed package also updates the boot firmware to the 2020-02-12 version (as our boot firmware was several months, and versions out of date too).
Brian Murray (brian-murray) wrote : | #6 |
I flashed the focal preinstalled image for arm64 and put in an RPi4. I then did a dist-upgrade, setup a netplan config, rebooted (an undocumented step?) and I am not able to connect to the access point. I confirmed that the right firmware is being used:
[ 9.005150] brcmfmac: F1 signature read @0x18000000=
[ 9.014444] brcmfmac: brcmf_fw_
[ 9.025103] usbcore: registered new interface driver brcmfmac
[ 9.280853] brcmfmac: brcmf_fw_
[ 9.301187] brcmfmac: brcmf_c_
[ 10.310028] brcmfmac: power management disabled
I found this in my journal:
Feb 19 19:28:14 ubuntu wpa_supplicant[
Feb 19 19:28:22 ubuntu wpa_supplicant[
Feb 19 19:28:29 ubuntu wpa_supplicant[
Feb 19 19:28:37 ubuntu wpa_supplicant[
Feb 19 19:28:44 ubuntu wpa_supplicant[
Feb 19 19:28:52 ubuntu wpa_supplicant[
Feb 19 19:29:00 ubuntu wpa_supplicant[
Feb 19 19:29:07 ubuntu wpa_supplicant[
Perhaps we should test this on 19.10.1 so we aren't adding the additional variable of running Focal.
Dave Jones (waveform) wrote : | #7 |
> Perhaps we should test this on 19.10.1 so we aren't adding the additional variable of running Focal.
I've added an Eoan version of the package to the same PPA (https:/
Brian Murray (brian-murray) wrote : | #8 |
I've tested this today on both 20.04 (with linux-firmware-
I see the same journal entries mentioned previously:
Mar 10 20:57:10 ubuntu wpa_supplicant[
Mar 10 20:57:18 ubuntu wpa_supplicant[
Additionally, I notice that the output of 'iw dev' shows different channels and widths than on Raspbian:
Interface wlan0
Brian Murray (brian-murray) wrote : | #9 |
I decided to test this with the armhf version of 20.04 given that Raspbian is armhf only and the results were the same.
Launchpad Janitor (janitor) wrote : | #10 |
This bug was fixed in the package linux-firmware-
---------------
linux-firmware-
* New upstream release, 1.20200212
* Updated wifi firmware to support 802.11ac wifi (LP: #1862760)
* Added diversions to override linux-firmware's versions of the wifi
firmware (LP: #1862146)
-- Dave Jones <email address hidden> Tue, 10 Mar 2020 11:46:49 +0000
Changed in linux-firmware-raspi2 (Ubuntu Focal): | |
status: | New → Fix Released |
Changed in linux-firmware-raspi2 (Ubuntu Focal): | |
status: | Fix Released → Triaged |
tags: | added: id-5e42d5f1bfa3f21352dd8e14 |
Brian Murray (brian-murray) wrote : | #11 |
I managed to get my RPi4 to connect to the 802.11ac access point by setting the regulatory domain to US - "iw reg set US". Here's a before and after output of "iw reg get".
ubuntu@ubuntu:~$ iw reg get
global
country 00: DFS-UNSET
(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)
ubuntu@ubuntu:~$ iw reg get
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
However, this is much different than my 20.04 laptop running Ubuntu.
Brian Murray (brian-murray) wrote : | #12 |
Here's the "iw reg get" output from a 20.04 laptop.
[ 10:58AM 10014 ] [ bdmurray@speedy:~ ]
$ iw reg get
global
country 00: DFS-UNSET
(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 (self-managed)
country US: DFS-UNSET
(2402 - 2437 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-80MHZ, NO-160MHZ
(2422 - 2462 @ 40), (6, 22), (N/A), AUTO-BW, NO-80MHZ, NO-160MHZ
(2447 - 2482 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-80MHZ, NO-160MHZ
(5170 - 5190 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5190 - 5210 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5210 - 5230 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5230 - 5250 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5250 - 5270 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5270 - 5290 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5290 - 5310 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5310 - 5330 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5490 - 5510 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5510 - 5530 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5530 - 5550 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5550 - 5570 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5570 - 5590 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5590 - 5610 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5610 - 5630 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5630 - 5650 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5650 - 5670 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5670 - 5690 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5690 - 5710 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5710 - 5730 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5735 - 5755 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
(5755 - 5775 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
(5775 - 5795 @ 80), (6, 22), (N/A), AUTO-BW,...
Brian Murray (brian-murray) wrote : | #13 |
On Raspbian the output of "iw reg get" matches what I saw after setting "iw reg set US".
Seth Forshee (sforshee) wrote : | #14 |
Generally speaking we don't know what country a device is operating in, so we default to the world domain which should be safe throughout the world. The AP may send a hint to the client as to what regulatory domain to use, but many APs do not do this.
Also note that on many desktop systems now the regulatory domain is managed by the wireless card firmware, which is why you may see the domain set there even if the AP does not send a hint.
Brian Murray (brian-murray) wrote : | #15 |
Just to be clear this is what iw reg get shows on Rasbian:
pi@raspberrypi:~$ iw reg get
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
Seth Forshee (sforshee) wrote : | #16 |
Based on some quick googling, I think there's some localization set up on raspbian that must also cause it to set the regulatory domain.
https:/
Brian Murray (brian-murray) wrote : | #17 |
I went ahead and ran through the Raspbian setup again and this time I said I was in the UK. After that and rebooting I ran 'iw reg get' and the results showed "country GB: DFS-ETSI".
Jerry Vonau (jvonau) wrote : | #18 |
Think this might relate to how netplan constructs its /run/netplan/
1. https:/
2. https:/
3. https:/
4. https:/
Jerry Vonau (jvonau) wrote : | #19 |
Looks like the ssid_scan= is being addressed upstream
https:/
no longer affects: | linux-raspi (Ubuntu Bionic) |
no longer affects: | linux-raspi (Ubuntu Eoan) |
no longer affects: | linux-raspi2-5.3 (Ubuntu Focal) |
no longer affects: | linux-raspi2-5.3 (Ubuntu) |
Juerg Haefliger (juergh) wrote : | #20 |
I'm not able to reproduce this issue but I can't restrict my router to use 802.11ac only, it also uses 802.11n in the 5GHz spectrum. Is there a way to check which standard is in use for a connection or is it possible to restrict which standard to use on the client side?
Brian, are you still seeing this issue with a current focal image and kernel 5.4.0-1009?
FWIW, my log:
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd[1]: Starting Network Service...
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd[1]: Started WPA supplicant for netplan wlan0.
Apr 29 06:17:46 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd[1]: Started Network Service.
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf systemd-
Apr 29 06:17:46 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:47 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:48 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:49 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:50 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:51 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:52 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:53 rpi-4b-rev1d1-17cf kernel: ieee80211 phy0: brcmf_escan_
Apr 29 06:17:55 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:58 rpi-4b-rev1d1-17cf iwd[1176]: Unexpected connection related event -- is another supplicant running?
Apr 29 06:17:58 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:17:58 rpi-4b-rev1d1-17cf wpa_supplicant[
Apr 29 06:...
Jerry Vonau (jvonau) wrote : | #21 |
Think the regulatory domain is not being set anywhere as /etc/default/crda has REGDOMAIN= and sudo cat /run/netplan/
ctrl_interface=
network={
ssid=
key_mgmt=WPA-PSK
psk="nope"
}
Might explain 'ieee80211 phy0: brcmf_escan_
https:/
For manual changing of regulatory domains use iw (iw reg set) or wpa_supplicant.
Juerg Haefliger (juergh) wrote : | #22 |
Maybe related? https:/
Brian Murray (brian-murray) wrote : | #23 |
The Eoan Ermine has reached end of life, so this bug will not be fixed for that release
Changed in linux-firmware (Ubuntu Eoan): | |
status: | New → Won't Fix |
Changed in linux-firmware-raspi2 (Ubuntu Eoan): | |
status: | New → Won't Fix |
Changed in linux-raspi2-5.3 (Ubuntu Eoan): | |
status: | New → Won't Fix |
Changed in netplan.io (Ubuntu Eoan): | |
status: | New → Won't Fix |
tags: | added: fr-374 |
pcgeek86 (pcgeek86) wrote : | #27 |
I just tried to set up Ubuntu 20.04.1 LTS Focal Fossa on a Raspberry Pi 3 B+ and ran into this bug. I used the ARM 64-bit image from this page: https:/
I was able to use my 2.4Ghz SSID just fine. Tried switching back to the 5Ghz and failed. Went back to 2.4Ghz for now.
Juerg Haefliger (juergh) wrote : | #28 |
What kernel and firmware versions? 20.04.1 is quite old. Have you tried updating?
True-night (hlpimfalling) wrote : | #29 |
Hi all, I found that adding the correct region to the /etc/default/crda file resolved my 5GHZ woes on the raspi4b ubuntu 20.10. After a reboot it finally connected to my 5GHZ network. Just putting this out there if it helps anyone.
Juerg Haefliger (juergh) wrote : | #30 |
Somewhat related: LP: #1908951
I'm actually getting good results using the updated brcmfmac43455 firmware files which Raspbian is using. To use them I first removed '/lib/firmware/ brcm/brcmfmac43 455-sdio. raspberrypi* ' then put the brcmfmac43455-sdio* files in the same directory and rebooted.
ubuntu@ubuntu:~$ cat /etc/lsb-release RELEASE= 18.04 CODENAME= bionic DESCRIPTION= "Ubuntu 18.04.4 LTS" MULTICAST, UP,LOWER_ UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 32ff:fe37: 3708/64 scope link brcm/brcmfmac43 455-sdio. * 74ee88b4f85cb1f 4f /lib/firmware/ brcm/brcmfmac43 455-sdio. bin 870986c517963fe f7 /lib/firmware/ brcm/brcmfmac43 455-sdio. clm_blob f701460436c6862 26 /lib/firmware/ brcm/brcmfmac43 455-sdio. txt 0x15264345 alloc_request: using brcm/brcmfmac43 455-sdio for chip BCM4345/6 455-sdio. raspberrypi, 4-model- b.txt failed with error -2 alloc_request: using brcm/brcmfmac43 455-sdio for chip BCM4345/6 preinit_ dcmds: Firmware: BCM4345/6 wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
Unnamed/ non-netdev interface
wdev 0x2
addr 52:4f:c2:5b:63:7a
type P2P-device
txpower 31.00 dBm
ifindex 3
wdev 0x1
addr dc:a6:32:37:37:08
ssid Linksys01146_5GHz
type managed
channel 44 (5220 MHz), width: 80 MHz, center1: 5210 MHz
txpower 31.00 dBm
DISTRIB_ID=Ubuntu
DISTRIB_
DISTRIB_
DISTRIB_
ubuntu@ubuntu:~$ ip address show wlan0
3: wlan0: <BROADCAST,
link/ether dc:a6:32:37:37:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.111/24 brd 192.168.1.255 scope global dynamic wlan0
valid_lft 85747sec preferred_lft 85747sec
inet6 fe80::dea6:
valid_lft forever preferred_lft forever
ubuntu@ubuntu:~$ md5sum /lib/firmware/
963eb0d49030409
c5aeca0e33de4ae
7b983812a8aee7b
ubuntu@ubuntu:~$ dmesg | grep brcmfmac
[ 12.265990] brcmfmac: F1 signature read @0x18000000=
[ 12.271828] brcmfmac: brcmf_fw_
[ 12.284536] usbcore: registered new interface driver brcmfmac
[ 12.355127] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43
[ 12.548549] brcmfmac: brcmf_fw_
[ 12.579186] brcmfmac: brcmf_c_
[ 13.578117] brcmfmac: power management disabled
ubuntu@ubuntu:~$ iw dev
phy#0
Interface wlan0
For the record I'm connecting to a Linksys EA7450 wireless access point and I've restricted the 5GHz frequency to 802.11ac only.