RPi-Distro/firmware-nonfree

brcm/brcmfmac43455-sdio for chip BCM4345/6 Power mgmt Issue

pinkforest opened this issue · 5 comments

Client mode - quiet stable environment - Quality=69/70 Signal level=-41 dBm

After couple of hours generally the wlan freezes and requires manual intervention yo-yo on the kmod.

No other traffic on wlan0 than crontab */5 (minute) that pings 5 packets the gateway each which invokes rmmod and mogprobe to get the wifi back up (cheap work/around) if the ping on gateway fails.

5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l GNU/Linux

This is with the January 2021 version brcm/brcmfmac43455-sdio.bin 7.45.229

[13522.321815] ieee80211 phy3: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[13522.321837] ieee80211 phy3: brcmf_cfg80211_get_tx_power: error (-5)
[13523.073220] usbcore: deregistering interface driver brcmfmac
[13523.205160] brcmfmac: F1 signature read @0x18000000=0x15264345
[13523.210950] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[13523.298242] usbcore: registered new interface driver brcmfmac
[13523.379491] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[13523.379560] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[13523.385809] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Jan 4 2021 19:56:29 version 7.45.229 (617f1f5 CY) FWID 01-2dbd9d2e
[13523.563567] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[13527.276685] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[13528.311429] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled

I'll PR new official Apr 15 2021 (7.45.234) from Cypress for brcm/brcmfmac43455-sdio

Validating stability in client mode with the following APs

Had the issue with Idling

  • 2.4Ghz FritzBox 7490 (FritzOS 07.28) - channel fixed to 6 - WPA2 - once 2 hours when Idling

If the firmware fixes the stability issue will report back.
If the issue persists will enable more debug (trying to rule out above first)

Will gather more guinea pigs.

7.45.241 firmware has been pushed to the bullseye branch (https://github.com/RPi-Distro/firmware-nonfree/tree/bullseye/debian/config/brcm80211/cypress, with symlinks from .../brcm).

@pinkforest can you elaborate on "channel fixed to 6 - WPA2"? I've observed potentially similar behavior recently with OpenWRT in client mode when connecting to Cisco enterprise equipment with a Pi 4B - the device shows quite a propensity to connect to 2.4 GHz APs on channel 6. Not always, but it happens frequently that it gets stuck on a channel 6 AP that provides inferior connection quality. Occurs with roamoff=0 or roamoff=1, no visible change in behavior between the two.

I'm still trying to track this behavior down, but it happens to occur even with old firmware blobs (as I tried to pull in new blobs to fix this issue), so may be somewhere in the driver - but if someone else is seeing similar behavior with a single non-Cisco AP then it isn't my first guess at root cause (configuration change on the AP/controller side of things).

@Entropy512 Instead of relying auto-negotiation we used the fixed channel 6 which was free of interference otherwise.

Since I have not been able to come up with exact replication remotely and I don't have access to these affected boards physically myself I have to close this issue. I assumed this was something to do with the firmware but these problems persist with .241.

We've tried to rule out all the thermal / power / hardware issues but we still haven't found a cause why this happens seemingly randomly intermittently with few of friend's boards.

I have those APs somewhere and I will double check any compatibily type of issues with various settings.

Thanks for the info. Turns out the channel 6 issue I'm seeing is almost surely not what you are seeing after further investigation.