brcmfmac: brcmf_sdio_hostmail: mailbox indicates firmware halted

[beta-tester]

Describe the bug
hello, i have:

• RPi4B (4GB)
• official Raspberry Pi power supply (no undervoltage messages in syslog)
• Raspbian (Raspberry Pi OS) updated & upgraded
• proper cooling (no above 60°C).

on that RPi i run an access point (hostapd + dnsmasq) on its onboard wifi interface wlan0.
to that access point (wlan0) i connected wifi sensor devices, those are sending its data to my RPi.
so far, so good...
it was working more than 6 month, 24h per day , 7 days a week - only few reboots after bigger updates,

but recently in some situations the wifi interface wlan0 stops working
and only a reboot of the RPi will bring back the wifi adapter back to life.

i think the main cause is the folowing message:
brcmfmac: brcmf_sdio_hostmail: mailbox indicates firmware halted

before it breaks, one of the most distant wifi sensor device with the worst signal was reporting to see the access point with only -85dB...

# a log i made to see the signal strength how strong the sensor can see the access point
2020-06-01T18:35:50.0;-84dB
2020-06-01T18:36:20.0;-85dB
2020-06-01T18:36:50.0;-80dB
2020-06-01T18:37:35.1;-81dB
2020-06-01T18:37:50.0;-85dB
2020-06-01T18:38:50.1;-84dB

and on the RPi4 in the /var/log/syslog there is the folowing to see...

Jun  1 18:42:29 pxe-server hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
Jun  1 18:42:29 pxe-server hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
...
Jun  1 18:44:02 pxe-server kernel: [68600.849888] brcmfmac: brcmf_sdio_hostmail: mailbox indicates firmware halted
Jun  1 18:44:10 pxe-server kernel: [68609.019622] brcmfmac: brcmf_escan_timeout: timer expired
Jun  1 18:44:13 pxe-server kernel: [68611.579693] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
Jun  1 18:44:13 pxe-server kernel: [68611.580127] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
Jun  1 18:44:13 pxe-server kernel: [68611.580141] brcmfmac: brcmf_notify_escan_complete: Scan abort failed
Jun  1 18:45:03 pxe-server kernel: [68661.430542] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
Jun  1 18:45:03 pxe-server kernel: [68661.430992] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
Jun  1 18:45:03 pxe-server kernel: [68661.431010] brcmfmac: brcmf_run_escan: error (-110)
Jun  1 18:45:03 pxe-server kernel: [68661.431025] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
Jun  1 18:46:03 pxe-server kernel: [68721.421553] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
Jun  1 18:46:03 pxe-server kernel: [68721.422013] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
Jun  1 18:46:03 pxe-server kernel: [68721.422032] brcmfmac: brcmf_run_escan: error (-110)
Jun  1 18:46:03 pxe-server kernel: [68721.422047] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
Jun  1 18:46:51 pxe-server kernel: [68769.822379] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
Jun  1 18:46:51 pxe-server kernel: [68769.822741] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
Jun  1 18:46:54 pxe-server kernel: [68772.382417] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
Jun  1 18:46:54 pxe-server kernel: [68772.382774] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
Jun  1 18:46:54 pxe-server kernel: [68772.382793] brcmfmac: brcmf_cfg80211_get_station: GET STA INFO failed, -110
...

this is already the third extra long weekend (because of holiday), that i can observe such an behavoir...

• it always starts with a weak signal strength on one of the wifi client.
  the client reports -85dB rx signal strength for the wifi access point.

• then there is a bunch of messages related to the client with the weak signal:
  hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: disassociated
hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated

• but the communication completely breaks as soon the folowing message appears in the log
  brcmfmac: brcmf_sdio_hostmail: mailbox indicates firmware halted

• from this point, the log file will be filled with endless messages of:

brcmfmac: brcmf_escan_timeout: timer expired
brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
brcmfmac: brcmf_notify_escan_complete: Scan abort failed
brcmfmac: brcmf_run_escan: error (-110)
brcmfmac: brcmf_cfg80211_scan: scan error (-110)

• after that the wifi adapter is not recoverable anymore until i reboot the RPi4.
  the wlan0 is dead - no wifi client is able to connect.

• a regular normal re-boot after this situation takes for ever, because stopping jobs of wlan0 / hostapd / dhcpsd run into timeouts at least for 3 minutes...

does anybody know, what is going on here?

that is happens mostely on extra long weekends with holidays.
i guess is because there are more wlan activity in the neighborhood speacially at those times.

but why seems the firmware to break in those situation so badly that only a reboot can bring the wifi adapter back to life?

[beta-tester]

$ sudo rpi-eeprom-update -a
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTFS /boot
BOOTLOADER: up-to-date
CURRENT: Thu Apr 16 17:11:26 UTC 2020 (1587057086)
 LATEST: Thu Apr 16 17:11:26 UTC 2020 (1587057086)
 FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad

[pelwell]

Since you seem to be able to get failures fairly regularly, can you try enabling some kernel debug output?
Add brcmfmac.debug=0x100000 to /boot/cmdline.txt, keeping it in a single, long line, then reboot. Running dmesg | grep brcmfmac should result in output like this:

[    7.650239] brcmfmac: CONSOLE: d 0
[    7.650256] brcmfmac: CONSOLE: 000000.063 wl0: Broadcom BCM4345 802.11 Wireless Controller 7.45.202 (r724630 CY)
[    7.650270] brcmfmac: CONSOLE: 000000.064 TCAM: 256 used: 252 exceed:0
[    7.650284] brcmfmac: CONSOLE: 000000.065 reclaim section 1: Returned 122844 bytes to the heap
[    7.650297] brcmfmac: CONSOLE: 000000.065 reclaim section 4: Returned 44 bytes to the heap
[    7.650310] brcmfmac: CONSOLE: 000000.065 sdpcmd_dpc: Enable
...

Then just carry on as normal. When the brcmfmac firmware dies, capture the output of dmesg to a file and attach it (or a link to pastebin, etc.) here.

Since the failure triggers other kernel messages, there is a danger that the useful output is lost before you have chance to capture it. A way to avoid this is to leave a shell constantly saving the kernel messages to a file:

$ dmesg -w > kernel_log.txt &

[beta-tester]

here is a syslog (with enabled debug information) of that issue from boot to shutdown/reboot...
hope you can see something usefully in there...
i kept also dnsmasq logs in there to see possible relationships...
xx:xx:xx:xx:xx:xx with the name sensor_tx_2 is the wifi sensor with the weak rx.
zz:zz:zz:zz:zz:zz is the onboard wlan0

at 11:34:30 the firmware is halted
syslog_log-1.txt.zip

PS.: i can not force the issue by slowly covering the sensor with a metal case.
the result is then simply no signal and will recover as soon the signal strength is good again.

[pelwell]

Thanks - I've forwarded your log and background information to Cypress.

[pelwell]

Cypress have responded very quickly with a new firmware to try - there's no indication yet what might have changed.

1. Download the new firmware from here: https://drive.google.com/file/d/1vz30u4UFWWA8Uh5ivo78ppYkUK3rh8fC/view?usp=sharing
2. Make a backup - sudo mv /lib/firmware/brcm/brcmfmac43455-sdio.bin{,.orig}
3. Install the new version - sudo cp brcmfmac43455-sdio.bin /lib/firmware/brcm/
4. Reboot.

If you do get another crash, please attach the kernel log as before.

[beta-tester]

wow, that is really quick!
thank you very much, i will try the new firmware and report if i still have issues.

but maybe it will take quite some time because i haven't figure out how to force the issue manually... so the only thing i can do is waiting...

[pelwell]

Of course - when you are waiting for a failure, no news is good news.

[beta-tester]

intermediate report:
til now no issues. the wlan is working now as it should.

BTW: the firmware reports:
BCM4345/6 wl0: May 20 2020 00:36:51 version manifest (de496ab CY) FWID 01-12aa6092
the date 2020-05-20 is already some weeks back in the past.
does it mean my RPi missed to pull this firmware update automatically (apt upgrade)
or is that firmware not released yet and will come later?

[pelwell]

Thanks for the update - I'll pass on the message. Cypress didn't state the history of that firmware or what might be different, but it is more recent than anything we have been given to release - you didn't miss it.

[pintify]

I'm currently experiencing this issue when I connect and eighth device to the WiFi AP. I'm on a Raspberry Pi 4 using hostapd to manage the AP.

This solution did not solve the issue:

Cypress have responded very quickly with a new firmware to try - there's no indication yet what might have changed.
1. Download the new firmware from here: https://drive.google.com/file/d/1vz30u4UFWWA8Uh5ivo78ppYkUK3rh8fC/view?usp=sharing
2. Make a backup - sudo mv /lib/firmware/brcm/brcmfmac43455-sdio.bin{,.orig}
3. Install the new version - sudo cp brcmfmac43455-sdio.bin /lib/firmware/brcm/
4. Reboot.
If you do get another crash, please attach the kernel log as before.

I attach the kernel log, but in a glance:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.118-v7l+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1311 SMP Mon Apr 27 14:26:42 BST 2020
[    0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
...
[    0.218661] brcm-pcie fd500000.pcie: could not get clock
[    0.218736] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[    0.218787] brcm-pcie fd500000.pcie:   MEM 0x600000000..0x603ffffff -> 0xf8000000
[    0.277680] brcm-pcie fd500000.pcie: link up, 5.0 Gbps x1 (!SSC)
[    0.277945] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
...
[    3.531376] brcmfmac: F1 signature read @0x18000000=0x15264345
[    3.540269] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    3.540607] usbcore: registered new interface driver brcmfmac
[    3.779925] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    3.793594] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2
[    4.761048] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    4.761065] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
[    4.932415] bcmgenet: Skipping UMAC reset
[    5.028318] bcmgenet fd580000.genet: configuring instance for external RGMII (no delay)
...
[   36.197929] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
<<--- The first seven devices are connected
[  154.775410] brcmfmac: brcmf_sdio_hostmail: mailbox indicates firmware halted <<--- As soon as I connect the eighth

Is there any alternative?

[pelwell]

It's a shame you didn't enable debug output from the firmware as I asked the issue creator to do - there is no useful information in the log.

I think you've probably reached the limits of the device+firmware combination, but I've asked Cypress how many clients should be able to connect.

[pintify]

That would be very interesting information. I will run again the issue with debug log activated.

[JamesH65]

Although certainly the firmware should not crash under these circumstances, looks like a buffer overflow or bad error handling somewhere.

[pintify]

I attach a log with debug log activated. The procedure is the same as in my previous comment:

kernel.log

[pelwell]

I see that's with the original firmware. Could you try again with the test firmware?

[pintify]

Sorry, I changed it back to test a different approach. This is a test applying the change you suggest:

kernel.log

[pelwell]

Thanks - I've passed that (and the other log) on.

[pelwell]

That second log that posted is using the original firmware again - it looks like you've failed to install the updated version.

After a successful installation you should get the following result:

pi@raspberrypi:~$ md5sum /lib/firmware/brcm/brcmfmac43455-sdio.bin
0a45a7a828e49e20fee2fe0438149523  /lib/firmware/brcm/brcmfmac43455-sdio.bin

If the md5sum doesn't match then you have the wrong file. After booting the kernel log will include:

[    7.111945] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: May 20 2020 00:36:51 version manifest (de496ab CY) FWID 01-12aa6092

Go through the installation instructions again, making sure that the download file is in the current directory before you run the cp. You can verify that you have the right file with:

pi@raspberrypi:~$ md5sum brcmfmac43455-sdio.bin
0a45a7a828e49e20fee2fe0438149523  /lib/firmware/brcm/brcmfmac43455-sdio.bin

[stelian42]

FYI, I have been experiencing the same kind of issues, quite reproductible after a few hours of operation.

I have updated to the test firmware and enabled the verbose driver logs, will report back if the crash happens again.

[pelwell]

Thanks - testing and feedback like that are invaluable.

[pintify]

I'm deeply sorry. Somehow I got confused with this similar answer, with a completely different version. The patch you suggest works better. The eighth device is still unable to connect but at least the driver doesn't crash. Now it reports this when the eighth device tries to connect and then it is rejected:

[ 4229.323079] brcmfmac: CONSOLE: 004205.908 wl0: wlc_userscb_alloc: no SCBs available to reclaim
[ 4229.323096] brcmfmac: CONSOLE: 004205.908 wl0: wlc_ap_authresp: out of scbs for 24:62:ab:f2:f6:70
[ 4229.323110] brcmfmac: CONSOLE: 004208.008 wl0: wlc_userscb_alloc: no SCBs available to reclaim
[ 4229.323123] brcmfmac: CONSOLE: 004208.008 wl0: wlc_ap_authresp: out of scbs for 24:62:ab:f2:f6:70
[ 4232.513075] brcmfmac: CONSOLE: 004209.300 wl0: wlc_userscb_alloc: no SCBs available to reclaim
[ 4232.513092] brcmfmac: CONSOLE: 004209.300 wl0: wlc_ap_authresp: out of scbs for 24:62:ab:f2:f6:70
[ 4232.513106] brcmfmac: CONSOLE: 004210.597 wl0: wlc_userscb_alloc: no SCBs available to reclaim
[ 4232.513120] brcmfmac: CONSOLE: 004210.597 wl0: wlc_ap_authresp: out of scbs for 24:62:ab:f2:f6:70
[ 4238.053053] brcmfmac: CONSOLE: 004211.894 wl0: wlc_userscb_alloc: no SCBs available to reclaim
[ 4238.053070] brcmfmac: CONSOLE: 004211.894 wl0: wlc_ap_authresp: out of scbs for 24:62:ab:f2:f6:70
[ 4238.053083] brcmfmac: CONSOLE: 004213.190 wl0: wlc_userscb_alloc: no SCBs available to reclaim
[ 4238.053097] brcmfmac: CONSOLE: 004213.190 wl0: wlc_ap_authresp: out of scbs for 24:62:ab:f2:f6:70

Is it caused by the limit of devices you suggested previously?

Thanks in advance

[pelwell]

I think it has to be because of resource limits, but I've not had confirmation of what the limit is supposed to be. I've seen a datasheet suggesting a maximum of 4 AP clients, so 7 isn't bad considering. Out of curiosity, how many devices does your phone's hotspot support?

[pintify]

In the past I've reached three devices but never explored the limit. I'll try to perform a test later if possible.

[pelwell]

Cypress have confirmed the 7-client limit.

[pintify]

Ok, that's a pity, but good news anyway. Thank you!

[pelwell]

There's another test firmware - the date is the same as the recent public release but the options list looks different (I have no other information): https://drive.google.com/file/d/10ivocg5PrOwVxAYFKOzJEdv_gdCd-IUF/view?usp=sharing

Be sure to rename to brcmfmac43455-sdio.bin when installing it.

[stelian42]

I didn't reproduced my hang issues with the updated firmware. Maybe I didn't wait enough.

Anyway, I have updated to the latest firmware and will continue testing:

$ md5sum /lib/firmware/brcm/brcmfmac43455-sdio.bin
c4d098fdac7b453408341d5709481b10  /lib/firmware/brcm/brcmfmac43455-sdio.bin

$ dmesg |grep "brcmfmac.*Firmware"
[    5.532513] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 23 2020 02:19:54 version 7.45.206 (r725000 CY) FWID 01-88ee44ea

[beta-tester]

i am wondering, why the new update goes back in time...?
the new one:
c4d098fdac7b453408341d5709481b10
Mar 23 2020 02:19:54 version 7.45.206 (r725000 CY) FWID 01-88ee44ea

the prevous new one:
0a45a7a828e49e20fee2fe0438149523
May 20 2020 00:36:51 version manifest (de496ab CY) FWID 01-12aa6092

the original one:
9d5d7f1953769b5ded866217c9afc437
Mar 2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2

[jvonau]

Think you might want to add https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=e12bc9cb438d67ddd64c596a907391d008248f7a if you don't want to make the jump to 4.19.129 or .130 from .118.
Thanks in advance.

[JamesH65]

There have been a lot of Linux kernel commits around brcmfmac coming from Cypress in the last while:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=brcmfmac

Are there any that appear particularly relevant e.g. that the Raspberry Pi community should be monitoring and/or advance-testing here?

I monitor all netdev and linux-wireless posts for anything relevant to both wired and wireless ethernet on the Pi, and pass any that might be of interest along. In the recent batch, we do not think there is anything vital , and I saw nothing about the number of available connections.

[dzett]

i am wondering, why the new update goes back in time...?
the new one:
c4d098fdac7b453408341d5709481b10
Mar 23 2020 02:19:54 version 7.45.206 (r725000 CY) FWID 01-88ee44ea

the prevous new one:
0a45a7a828e49e20fee2fe0438149523
May 20 2020 00:36:51 version manifest (de496ab CY) FWID 01-12aa6092

the original one:
9d5d7f1953769b5ded866217c9afc437
Mar 2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2

Just fyi, I stumbled upon this ticket while experiencing problems with Wifi disconnecting after longer periods of time (1 - 5 days) on a headless Raspberry PI 4B (up to date Raspbian installed), so I thought I'd give it a try as this is a quite recent conversation.

I tried out the Mar 23 firmware (01-88ee44ea) and my Wifi would only connect to the AP on the 5GHz band with unusable low signal strength (and also does not fall back to 2.4GHz).
I have now switched to the May 20 version and it does not show this connectivity issue, with a stable 5GHz connection.

So the Mar 23 one does not seem to be advisable.
If you want I can feed back whether my long-term connectivity issue also disappeared now that I am using the May 20 one.

[jvonau]

FYI June 25th https://community.cypress.com/docs/DOC-20044
Just extracted and renamed .bin and .clm_blob from cypress-firmware-v5.4.18-2020_0625.tar.gz and placed in /lib/firmware/brcm/

pi@box:~ $ dmesg | grep brcmfmac
[ 4.238330] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 4.248776] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 4.249158] usbcore: registered new interface driver brcmfmac
[ 4.491536] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 4.498227] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: May 22 2020 21:24:34 version 7.45.214 (9c83742 CY) FWID 01-59feefd4
[ 9.475492] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
pi@box:~ $ strings /lib/firmware/brcm/brcmfmac43455-sdio.bin | grep Version
43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv-gtkoe-roamprof-txbf-ve-sae-dpp-sr-okc-bpd Version: 7.45.214 (9c83742 CY) CRC: 1baae67b Date: Fri 2020-05-22 21:26:31 PDT Ucode Ver: 1043.2147 FWID 01-59feefd4

note .214 vs .206 or .202, not saying this will correct any known issue, but it works for me with wlan0 used for upstream and ap0 for hostapd.

[jvonau]

I added debugging with echo options brcmfmac debug=0x100000 > /etc/modprobe.d/brcmfmac.conf
Booted with wlan0 connected to upstream AP while hostapd is using ap0 bridged to br0 with 2 clients attached. dmesg-214 I'll note once setup correctly running on 'lite' I don't suffer from any of the firmware halted errors, but have noted errors when there is a desktop installed or when wlan0 and ap0 are not on the same channel. Hope this helps.

[ganeshs4]

@jvonau Is brcmfmac43430 for Raspberry pi3x and brcmfmac43455 for Raspberry pi 4? For raspberry pi 3b+ the instructions(issue - raspberrypi/linux#2453) were for file named brcmfmac43430. Thank you.

[pelwell]

There are a variety of devices on that thread, but 43430 is used on 3B and Zero W, while 43455 is on 3B+, 3A+ and 4B.

[jvonau]

@jvonau Is brcmfmac43430 for Raspberry pi3x and brcmfmac43455 for Raspberry pi 4? For raspberry pi 3b+ the instructions(issue - raspberrypi/linux#2453) were for file named brcmfmac43430. Thank you.

Select the firmware from cypress-firmware-v5.4.18-2020_0625.tar.gz based on what dmesg spits out for you, mine is a rpi4

brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6

so I used cyfmac43455-sdio.* files. Remember to back up your old files, rename the new files, reboot and happy testing.

[ganeshs4]

Thanks @jvonau and @pelwell. dmesg output:
[ 5.197393] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 5.440447] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 5.452819] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2

So 43455. However, I followed the instructions from raspberrypi/linux#2453 and replaced brcmfmac43430 and surprisingly that resolved the wifi issue I was having on my Raspiberry Pi 3B+. Any clue how that would be possible?

[ganeshs4]

I tried patching 43455 on my Rpi3B+ and it broke the wifi. I reverted the backup and the wifi is working now. So seems like for Rpi3B+ the file that needs to be replaced is brcmfmac43430(as indicated in raspberrypi/linux#2453).

[pelwell]

As I've said before, there is no 43430 on a 3B+. You can patch the firmware if it makes you feel better, but it won't change anything. Any apparent benefits must be attributed to random chance.

[ganeshs4]

thanks @pelwell - as you said encountered the issue again today.

This time patched with the test firmware which you provided here for 43455 #1403 (comment). Currently the rpi3B+ is working.

[pelwell]

That version of the firmware is now in the RPi-Distro/firmware-nonfree repo and will be in future package and image releases. It's version string is:

43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-lpc-pwropt-43455_ftrs-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv Version: 7.45.206 (r725000 CY) CRC: 3d58e5fe Date: Mon 2020-03-23 02:21:50 PDT Ucode Ver: 1043.2139 FWID 01-88ee44ea

[ganeshs4]

anyway to know starting which image version/name the change will be bundled?

[beta-tester]

recently (2020-07-01) through an upgrade (sudo apt update && sudo apt upgrade) I got the original firmware again... is this possible?

9d5d7f1953769b5ded866217c9afc437
Mar 2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2

$ ls -la /lib/firmware/brcm/brcmfmac43455-sdio.*
-rw-r--r-- 1 root root 624943 Jul  1 11:11 /lib/firmware/brcm/brcmfmac43455-sdio.bin
-rw-r--r-- 1 root root  14036 Jul  1 11:11 /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob
-rw-r--r-- 1 root root   2074 Jul  1 11:11 /lib/firmware/brcm/brcmfmac43455-sdio.txt

-rw-r--r-- 1 root root 624943 Apr 17 17:15 /lib/firmware/brcm/brcmfmac43455-sdio.bin.orig
-rw-r--r-- 1 root root 627387 Jun  4 10:59 /lib/firmware/brcm/brcmfmac43455-sdio.bin.beta1
-rw-r--r-- 1 root root 624943 Jun 18 18:41 /lib/firmware/brcm/brcmfmac43455-sdio.bin.beta2

[jvonau]

That version of the firmware is now in the RPi-Distro/firmware-nonfree repo and will be in future package and image releases. It's version string is:

43455c0-roml/43455_sdio-pno-aoe-pktfilter-pktctx-lpc-pwropt-43455_ftrs-wfds-mfp-dfsradar-wowlpf-idsup-idauth-noclminc-clm_min-obss-obssdump-swdiv Version: 7.45.206 (r725000 CY) CRC: 3d58e5fe Date: Mon 2020-03-23 02:21:50 PDT Ucode Ver: 1043.2139 FWID 01-88ee44ea

It appears that the '.206' version didn't make it into the July 1st release of firmware-brcm80211-20190114-1+rpt7, as the commit with what I assume to be 206 was reverted prior to publishing '+rpt7'. Any idea when this might be released?

[holta]

FYI two tables were published earlier today, documenting the very serious downward trend in Raspberry Pi WiFi capacity, as well as some serious crashiness in Raspbian / Raspberry Pi OS's current firmware (7.45.202) for 3 B+ and RPi 4:

iiab/iiab#823 (comment)

As it affects those using Raspberry Pi's as learning hotspots / medical hotpots / community hotspots etc. Thanks to the many who contributed to this initial & ongoing analysis, hoping we can all get ourselves out of this ugly rut together over the coming months!

[satmandu]

@holta Worth noting that Cypress may be reallocating ram/resources on the chip not to necessarily enable fancy features but to fix security and/or stability issues in the wifi stack.

Thanks for putting together a table of which firmware supports what. For those of us interested primarily in wifi client performance/stability instead of use as an access point, perhaps there could be an option for which firmware is used.

(Also, I imagine that since Broadcom sold its wifi IP and product lines to Cypress, that a future RPI device might have other wifi options if they hit an appropriate price/performance point, especially if using Raspberry PIs as wifi access points continues to have popularity.)

[JamesH65]

Firstly we haven't asked for any new features from Cypress, we only ask for bug fixes. Whether they have added fancy new features I don't know. We have no access whatsoever to the Cypress source code so are entirely beholden to them to fix issues. This can be a time consuming process. We are a relatively small customer, with little leverage. If anyone has any suggestions how we can put any pressure on them to improve matters, I'd be all ears. Short of moving to another chip supplier with associated HUGE development costs and long (>year) timescales, I cannot see what the way forward is. We do continue to report issues to Cypress, and take what they give us back. I cannot reiterate enough that this change was nothing to do with us - we didn't ask for it and it's as big a surprise to us as it is to you.

[tim-moody]

we only ask for bug fixes

@JamesH65 in order for us to be clear on the implications of using old versions of the firmware is there a list anywhere of CVEs addressed in a given firmware release?

[pelwell]

Not that we maintain. Looking through https://github.com/RPi-Distro/firmware-nonfree/commits/master will get you some of that.

[beta-tester]

only as reference related to the limit of number of devices in the WiFi firmware iiab/iiab#2853
there is a different firmware available that allowes a higher number.