brcmfmac: brcmf_set_channel: set chanspec fail, reason -52 #6049
Comments
|
I don't understand why you mention the brcmfmac message and not the rather more worrying: which happened 4 seconds earlier. How are you powering this Pi 5? Spontaneous errors like this that affect multiple subsystems are classic symptoms of insufficient power. |
|
Previously I boot rpi os via tf card without hat using official rpi power… wifi is also influenced and hardly to be connected, I supposed that this is the same issue, I will check later. Currently I use official adaptors to power rpi5, 5v3a power for hat, 3a is okay for the hat. Before I make power_save off, usually the nvme + power_save dmesg presents before brcmfmac instead of only nvme before brcmfmac |
|
|
Nice. Cause: Effect: It was going OK until you plugged in an external HUB with a number of devices attached. Is that hub, or any of the devices, powered? |
|
This is a USB Hub (actually no power), however, I found I can't access it via ssh then I use USB to find what happened, I will try to see if this is true. It takes me time to test it, so wait and I will comment here |
|
Without nvme or usb issue, this network issue is still <\details> |
|
I now use powerful pcie bridge and samsung 980 SSD |
|
I can reproduce this. Freshly flashed RPI OS bookworm arm64 image, booted using microSD card, no peripherals attached except a keyboard. I'm using wpa_supplicant + systemd-networkd instead of NetworkManager. The syptoms are: high latency spikes (~1400ms), many packets dropped (too many). Seems to only appear on linux 6.6. If I disable wifi and use a wired connection, everything returns to normal. I reproduced this on two RPI Zero 2W, two RPI 4B, two RPI 5. (am I hoarding too many PIs...) |
|
I see these messages on a raspberry pi 4 running nixos - oddly the messages appear two days before the symptoms and I seem to need quite a bit of uptime before the issue occurs. The symptoms are the same though - the above message, high latency and packet drops. I can pinpoint exactly when the symptoms start and there's no logs around that time, apart from a service which is suddenly seeing the symptoms. Nothing else in The machine is left running and has no hardware (or other) changes made to it. |
Could I know which country wifi/internet you used? It seems that it's relevant to country? Could you also give the dmesg log? |
Sure, it's Great Britain (which matches where I am). Although perhaps the below output means it's unset for phy#0?
Of course, I've attached a few others and I've annotated with some thoughts as well (issue happens at 2024-04-18 09:30:25). Let me know if this isn't enough and you want it from boot: dmesgjournalctlfix (restarting `wpa_supplicant`)restarting wpa_supplicant sorted it: Please let me know if I can provide anything else Possibly Related
|
This is actually network related… |
|
Yeah fair paint, interesting that I see no issues until ~36 hours later - I wonder if there's some bug in the firmware, like the kernel UAF (which would explain why some people see success in simple fixes, while others need a reboot). |
|
We're seeing a similar issue on Ubuntu (LP: #2063365), but
On Ubuntu we see the same messages, but they also spam the console there as our printk defaults are a little different (level 4 instead of 3 on RaspiOS) |
|
It's not clear where they are coming from, but I'm pretty sure that the chanspecs that are being complained about are indeed invalid, i.e. illegal frequencies or widths. |
|
It doesn't appear to be network-manager specific; I can reproduce the same messages with networkd in control of the interface, but it's notable in both cases wpa_supplicant is handling the interface (I haven't tried iwd yet). One other thing I did note, which may or may not be relevant, is that my interface happily sets its own regulatory domain implicitly these days (presumably the AP's setting the right "regdom = GB" bits in its beacon), but the
Is it possible that the interface is trying channels that are permitted under regdom GB, but aren't under 00, because it "remembers" that the connection it's trying had regdom GB, but the interface isn't currently configured for that? It's wild speculation on my part, but might tie in with why the messages don't appear on initial boot -- the interface wasn't regdom GB before then -- but appear later when the interface is re-configured. |
|
Aha! This thread looks particularly relevant. Unfortunately it doesn't have a definite resolution (at the time of writing), but from a skim through I think it's describing this exact issue and the root cause. |
To confirm - I'm using plain
Nice find, referencing this mail for anyone following - seems to be the basis of a fix. Am I reading it right though, the thread seems to have gone quiet as of Feb (2024)? |
|
I am having the same issue on cm4 with WiFi on an official cm4 IO board using the latest bullseye 64bit lite image. I'm just entering the CM4 world so this stumped me for a while WiFi county set to GB If anyone knows a fix, an older kernel etc let me know. |
|
Same issue here on RPI3A+ with HASSIO.. |
|
I checked my WiFi country and my tp link router was constantly setting the country to DE if I like with is reg get. Even if I set it back it changed back on a restart. I got a new router and it seems to be fixed. |
|
device : RPi5, powered by POE Hat; USB 2.0 keyboard connected issue appeared after setting up steps to reproduce:
Details
|
|
Same issue here |
|
Also having this issue on a RPI 5 running Raspberry Pi OS (Debian 12.5 Bookworm). Used to run a webserver. Started occurring sometime in the last month or so. Also have a TP-Link router, but I wasn't able to get it to broadcast any beacons containing country code (I might not be doing it correctly though). Anyways I noticed something that seemed odd to me:
iw event outputStill not sure of the actual issue, but thought I would share. |
I have some sort of same issue where I can't find my network after a while. I couldn't exactly pinpoint it though. |
|
I am seeing the same issue. I have tried both NetworkManager and wpa_supplicant with systemd and both of them eventually drop my wifi and I have to reboot. Sometimes its everyday or every 3 days. I have set my country code but I still get disconnects. I am running Arch Linux on a Rpi5 and I have a TP-Link router. I am like 6 feet from the router so it is close enough with no walls in between. I wish I could figure this out. |
|
There may be some value in investigating if firmware changes such as those mentioned in NixOS/nixpkgs#82462 work, I won't have access to my machine for a while but that's my next step. |
I'm experiencing the same issue on my Raspberry Pi 4B running Raspbian Bookworm with kernel 6.6.28+rpt-rpi-v8. My Pi is connected to my WiFi home router using the 5.24 GHz band. Coincidentally I have several 2.4-GHz devices in my home network which use services running on the Pi. Not sure if that could be related to this particular issue, but never experienced it before. I've enabled some debug options for the brcmfmac module, but honestly, I'm rather clueless about what to look for or which flags I should enable. Maybe someone with a better understanding of the module source code can point out which bits are worth enabling to better diagnose this behaviour (options taken from FMAC Debugging) It also might be worth noting that I tested both with WiFi power management enabled and disabled. I'd say that with power management enabled the percentage of lost packets is lower. It's very common for users to disable power management because it's common to find that recommendation when searching for solutions to WiFi connectivity issues. The following are kernel logs from the The CRDA regulatory domain (ES) had been defined both for I initially thought this to be an SSH server issue, as I was receiving the following message when running ssh with increased verbosity: |
|
Observed the same issue with a CM4 based device and 6.6 kernel, but they went away after the installation of the |
I did this but my RPi4 (Ubuntu 24.04) still doesn't scan any 5g wifi networks.. |
|
Just to repeat as there has been a lot of recent noise on this issue, putting in |
|
I added at |
That's not really the scope of this problem.. is the network you're trying to see a WPA3-only network perhaps? Even the base Raspberry Pi image does not support WPA3 yet. Also you're using Ubuntu, have you tried the standard Raspberry Pi OS install? If it works in Raspberry Pi OS and not in Ubuntu then that's an Ubuntu problem not a Raspberry Pi Wi-Fi issue. |
It's a standard WPA2-PSK wifi.. I can't really experiment with Raspbian, I am not on-site and I do everything remotely. |
holta
added a commit
to holta/iiab
that referenced
this issue
Mar 28, 2025
|
|
I, too, have been getting this problem a lot as I've been updating my Pi 5s that are using a 5 Ghz WiFi network... I can replicate it by restarting NetworkManager sometimes, I end up with: It seemed to happen more often after a reboot or restarting NM, but I've had it happen on cold boots sometimes too. Always after upgrading from the last Pi image version at 6.6.x to now 6.12.x. I tried adding in the options mentioned above to |
To rule out the
...and don't forget to reboot! |
|
New firmware out ( Anyone know if this is meant to improve things and we no longer require the 0x282000 and roamoff workarounds or am I getting my brcm packages confused and the workarounds still stand? I also found: RPi-Distro/firmware-nonfree@281937c Update: Actually not sure what this updated as |
I tried that and my Pi 4B still got stuck at night :( It gets so stuck that even holding the power button doesn't restart it, I need to pull out the plug. |
That sounds like more than just a WiFi issue.. try a different SD card and a high quality power supply (the official USB power supply being the recommended one).. and revert any overclocking (if applicable). Do you have a display connected? Are you able to see if there are any kernel panics? |
I'm using the official power supply. The SD card is a Samsung, and it works fine. Pi is not overclocked. UPDATE: The power button was broken, I had to reinstall the argonfanhat.sh script. Pi still gets disconnected from the network, though. It doesn't have a display, I use it as a server. Last boot logs look like this: |
sairon
added a commit
to home-assistant/buildroot
that referenced
this issue
Apr 15, 2025
Bump version to the latest synced version from RPi OS that adds firmware for new chipsets and updates BCM43455 SDIO firmware. The old firmware has some features missing which can result in the driver returning errors like: brcmf_set_channel: set chanspec 0xd099 fail, reason -52 This was tracked down [1] to usage of DUMP_OBSS feature, and while disabling this feature is a potential workaround, updating the firmware is actually the correct solution to the problem. Buildroot is using downstream kernel 6.6 already since 51b4421, so the firmware should be bumped to what RPi OS uses at this point too. [1] raspberrypi/linux#6049 (comment) Signed-off-by: Jan Čermák <[email protected]>
|
Hello everyone, thanks for all the great inputs here. I added the below line to my HAOS (15.2 connected via external ssd) running on Raspberry Pi 5. Even then, I still see the error "brcmfmac: brcmf_set_channel: set chanspec fail, reason -52" and the 5GHZ wifi connection is a hit or miss after reboot. I have separate SSIDs for my 2.4g and 5g network. I also have the same HAOS version running on a 128GB Samsung EVO micro SD card and behavior is same. Using 2.4G does not seem to have any issues. Any help is greatly appreciated options brcmfmac feature_disable=0x82000" > /etc/modprobe.d/brcmfmac.conf |
|
Upgrading the firmware (through the normal |
Thank you, sarna. As far as I have read apt is not supported on HAOS. I get command not found error when using apt. However, I believe I have the latest firmware already. brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b Any HAOS users here who are able to get this working ? Thanks in advance ! |
@sarna Add the disable feature to fix the set chanspec errors (which is what this issue is about).. I recommend doing the full
@shanmukhad Try in the cmdline.txt as modprobe.d may have some conflicting values which are over-riding your .conf and don't forget to reboot. Also I recommend 0x282000 and including roamoff as above. |
@Matthew1471 I don't need to do that, since that firmware upgrade fixed these errors completely for me. |
|
@sarna: is actually built into latest firmware-nonfree 1:20240709-2~bpo12+1+rpt3 release, as per RPi-Distro/firmware-nonfree@2788cb5 |
I thought there was an update but unless the firmware version didn't change it's still the same firmware: #6049 (comment)
That explains a lot, the "RPI Distro" already includes the workarounds |
|
Thank you, @Matthew1471 . Thr below command in the cmdline.txt did not work for me. Is there a way to upgrade the brcm firmware in HAOS ? Yum/apt are not working. brcmfmac.roamoff=1 brcmfmac.feature_disable=0x282000 |
I don't use HAOS but however you specify command line arguments to the Linux kernel is how you pass those 2 values.. they should be at the end of the line so for instance in my Raspberry Pi OS As you see it's at the end of You need to reboot afterwards after adding those 2 params too. If you have dpkg you can usually copy a .deb file to it and do a local install of a package. |
|
@Matthew1471 , thank you. I no longer see the error messages. Earlier I added the same commands in a new line, now I moved them to the end of the exisitng line. Not sure if that was the difference. However, I am unable to connect to the 5g network after reboots in some occasions, it is still a hit or miss. I guess I have no option but to wait for HA to update the driver firmware when they release new HAOS versions. |
You're welcome. Yes I don't think newlines/linefeeds are allowed so none of those settings would previously have applied (but they are now they're on the same line).
Metal case? Signal strength good? Dodgy PMF/MFP implementation on the Access Point (does turning off PMF/MFP temporarily on the AP allow you to connect on reboot easy?)? I am not aware of any 5 GHz issues - nor have I experienced any since adding these options - but as I mentioned I'm using the official OS so it could be there's an out of date package somewhere on HAOS. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
I used the rpi5 with Mcuzone MPS2280P hat for SSD, I booted the archlinux arm from nvme SSD with linux-rpi.
RPi 5 still suddenly disconnects the internet and SSH and reports
brcmfmac: brcmf_set_channel: set chanspec fail, reason -52, especially when RPi 5 has file IO and msg output, for example, updating system, journalctl, downloading/uploading sth from/to internetAfter extra settings (see Additional context), strangely, when I initially trigger to connect the internet this issue won't present, when the internet was reconnected, it would present, so this is quite similar to the issue reported to the linux kernel, see
this mail list discussion, however, I'm still not sure, because after re-connecting the internet, it can't use internet like what additional note1 mentioned.
Without netctl/iwd/networkmanager starts, it's impossible to report
Steps to reproduce the behaviour
When I start the NetworkManger on Arch Linux ARM, I got the debug msg
Device (s)
Raspberry Pi 5
System
Logs
dmesg
systemd
Additional context
Try1
I also disable the power_save via adding file named /etc/NetworkManager/conf.d/powersave.conf
Before I did so, it won't use internet.
Try2
Before installing rpi5-eeprom, the internet can be connected, however, when I tried to use the internet for any ways or ssh to the rpi5, it suddenly disconnected.
After installing rpi5-eeprom, it can be connected, however, usually, it still suddenly disconnects the internet and SSH.
Additional note1
I remove the
kmsin/etc/mkinitcpio.confso, the final hooks are
Without doing so, I'll get the report
Additional note2
I found some posts suggested that this issue is a regulatory domain issue, then, I try to follow archwiki https://wiki.archlinux.org/title/Networ ... ory_domain
set like this
iw reg set <my_country>, add country= <my_country> line of /etc/wpa_supplicant/wpa_supplicant.confThe issue is still
The text was updated successfully, but these errors were encountered: