wlan freezes in raspberry pi 3B+ #2453
Comments
ghost
changed the title
|
Same problem here. If i do a: So i guess its kernel related. |
|
Interesting. So not in the current rpi-update, but in the next branch? Should make the particular change a bit easier to find. |
|
any news? |
|
Not had a chance to look yet. How do you provoke the problem? We've not had many reports on B+ Wifi failing in this way, so apparently it's unusual. Have you updated to the very latest 4.14.xx kernel? Does that make any difference? |
|
Once I have more details on how to replicate the issues, I can send the data to Cypress for investigation. The mailbox error, IIRC, is a firmware crash, so its not something we can really deal with here, since we do not have access to the firmware. |
JamesH65
added
the
Waiting for external input
|
It may be slightly off topic because it's a different distribution, but it's pretty easy to trigger this error when using Kali Pi. For reference, |
|
On a project I am working on, I am getting this constantly with Kali Pi when in monitor mode. Unloading and reloading the driver works sometimes and sometimes not. Sometimes it happens after 5 seconds, sometimes after 5 minutes, very random. Verified its not a hardware problem since I have 2 Pi's and both do it. I also loaded Raspbian latest and installed latest Nextmon drivers and I get the exact same thing, Kernel is 4.14.30-Re4son-v7+ on Kali. Don't have other offhand. |
|
Do you get any errors listed in dmesg? |
|
Yes I do.
The following is while running the following command, The Set Channel failed aren’t really errors it seems since I am scanning a range
/usr/sbin/airodump-ng -C 2412-5825 --write-interval 10 --write test --output-format netxml wlan0mon
Working until this point……..
[78833.305809] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[78835.790416] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78835.797410] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78835.803824] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=53409, -110
[78838.590434] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78838.597330] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78838.603733] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=53413, -110
[78841.390457] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78841.397407] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78841.403867] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=4098, -110
[78844.190483] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78844.197466] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78844.204088] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=4102, -110
[78846.990502] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78846.997678] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78847.004601] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=4106, -110
[78849.790519] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78849.797885] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78849.804936] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=4110, -110
[78852.590543] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78852.597968] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78852.605103] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=53284, -110
[78855.390563] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78855.398051] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78855.405211] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=53288, -110
[78858.190583] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78858.198319] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[78858.205591] brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=53292, -110
[78860.990609] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[78861.001145] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
…….
After shutting down airodump, I detected that it wasn’t capturing anything and attempted to unload at 79803.439351 and reload the driver at 79923.711128 and that failed.
I have a 120sec timer between unload and reload of driver
[79782.517551] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[79782.529849] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[79782.541559] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-110)
[79785.157565] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[79785.169936] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[79785.181530] brcmfmac: _brcmf_set_multicast_list: Setting mcast_list failed, -110
[79787.717590] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[79787.729703] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[79792.837633] brcmfmac: _brcmf_set_multicast_list: Setting allmulti failed, -110
[79797.957685] brcmfmac: brcmf_cfg80211_del_ap_iface: interface_remove failed -110
[79800.517694] brcmfmac: _brcmf_set_multicast_list: Setting BRCMF_C_SET_PROMISC failed, -110
[79803.078132] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[79803.089706] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-5)
[79803.187727] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[79803.199528] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[79803.210553] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-5)
[79803.439351] usbcore: deregistering interface driver brcmfmac
[79923.696268] brcmfmac: F1 signature read @0x18000000=0x15264345
[79923.700624] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
[79923.711128] usbcore: registered new interface driver brcmfmac
[79926.358647] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[79926.389146] brcmfmac: brcmf_c_get_clm_name: retrieving revision info failed (-110)
[79926.400840] brcmfmac: brcmf_c_process_clm_blob: get CLM blob file name failed (-110)
[79926.412661] brcmfmac: brcmf_c_preinit_dcmds: download CLM blob file failed, -110
[79926.423176] brcmfmac: brcmf_bus_started: failed: -110
[79926.431387] brcmfmac: brcmf_sdio_firmware_callback: dongle is not responding
… Tried unload and reload a little while later and it worked
[80685.169424] usbcore: deregistering interface driver brcmfmac
[80805.455360] brcmfmac: F1 signature read @0x18000000=0x15264345
[80805.460216] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
[80805.471390] usbcore: registered new interface driver brcmfmac
[80805.805728] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 10 2018 18:33:56 version 7.45.154 (nexmon.org: 2.2.2-178-gd64f-1) FWID 01-4fbe0b04
[80805.814840] 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
From: James Hughes [mailto:[email protected]]
Sent: Wednesday, June 6, 2018 4:11 AM
To: raspberrypi/linux <[email protected]>
Cc: Chris Douglas <[email protected]>; Comment <[email protected]>
Subject: Re: [raspberrypi/linux] wlan freezes in raspberry pi 3B+ (#2453)
Do you get any errors listed in dmesg?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2453 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGrL91e9G5lSPwp1PtKvluye60-lz8K8ks5t55yhgaJpZM4SwkCN>.
Click here<https://www.mailcontrol.com/sr/2xffoH0VKMPGX2PQPOmvUsgYVF5ojvBykkW9UzADy!8LKeLB79zZKi4csdmxhkuDqLqNh6I9BzeTKOxjbsImtQ==> to report this email as spam.
|
|
Any news about this? I'm having this same issue. From dmesg:
I wish I never executed the rpi-update; I finally got the Raspberry Pi 3 B+ working as an AP + Managed Wifi at 5GHz, but now the AP doesn't work anymore after the update. How can I downgrade the brcmfmac to a stable/working version? |
|
After "Unknown mailbox data content: 0x40012" is received, Sometimes it doesn't recover even after modprobe -r (device is stuck). technical comment: |
|
I’ll try it Monday and let you know. Thank you very much.
…Sent from my iPhone
On Jun 10, 2018, at 11:45 AM, gdb-power <[email protected]<mailto:[email protected]>> wrote:
After "Unknown mailbox data content: 0x40012" is received,
sometimes the communication can be recovered with the following commands:
modprobe -r brcmfmac
modprobe brcmfmac
Sometimes it doesn't recover even after modprobe -r (device is stuck).
In that case, the following heavy-handed commands will fix the communication with the wifi device:
echo -n "3f300000.mmc" > /sys/devices/platform/soc/3f300000.mmc/driver/unbind
sleep 1
echo -n "3f300000.mmc" > /sys/bus/platform/drivers/mmc-bcm2835/bind
technical comment:
rebinding the driver will call probe(),
which will call bcm2835_reset_internal(),
which will power-cycle the SDIO device (SDVDD_POWER_OFF),
which will properly reset the wedged WIFI SDIO device. Phew!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#2453 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGrL98NH4vq7R7-4fV5e33BpV9YdoCDTks5t7U0ZgaJpZM4SwkCN>.
Click here<https://www.mailcontrol.com/sr/FMgA5hvnUJvGX2PQPOmvUml+xXZX6IbqMNHcSExTXLGLfL5y4bkCVFXj2zyDaOvSKw2HpqN63pJ+U88fPeCTtg==> to report this email as spam.
|
|
@Nemesis7 You can revert to any previous firmware+kernel package using rpi-update by putting the hash (string of hexadecimal digits) on the command line. The hashes can be found on the right hand side of the list of commits (releases): https://github.com/Hexxeh/rpi-firmware/commits/master Alternatively you could return to the standard Raspbian kernel using: |
|
The heavy handed method seems to be working to get the driver working again, but is there a chance of this being fixed so its not necessary? Is this a hardware or firmware issue? Thank you |
|
@cdouglas97 We currently do not know the cause of this. The mailbox error is the result of the firmware on the wireless chip dying, but the cause of that is unclear. We do NOT have access to the firmware source, that is provided as a binary by Cypress so we do rely on them to fix firmware issues. I'm not looking at it at the moment, I have some other stuff to clear first. However, if anyone has a clear set of steps to replicate the problem on Raspbian, that would be very useful once I do start to look at it. |
|
Thank you. I can reproduce it very easily. Steps: wlan0 is not up, only active interface is eth0 Use Airmon-ng to create monitor port:/usr/sbin/airmon-ng start wlan0 Run airodump that scans all 2.4 to 5.8Ghz frequencies/usr/sbin/airodump-ng -C 2412-5825 --write-interval 10 --write OUTPUTME --output-format netxml wlan0mon It usually happens within 30 seconds to 5 minutes. I run the airodump for 60 seconds at a time with a 15 min gap between runs and then kill it so sometimes it completes its run and sometimes not. I added the heavy-handed commands before I start and it didn't seem to make a difference on how long it took for it to die. It just fixed the firmware if it died during a previous run. -Chris |
|
@cdouglas97 I am not familiar with airmon/airodump. What package do I need to install in Raspbian to get those? |
|
|
|
With wlan0 available but not associated with an AP I get: Any suggestions? |
|
pelwell, the default Rasbian latest install firmware doesn't allow monitoring, have to use this: https://github.com/seemoo-lab/nexmon to make it work. Kali uses this and I took a Raspbian image a built patch as directed and both get same result. |
|
Er, so the way to make this go wrong is to install some random third party stuff that plays around with the firmware in a way that probably wasn't intended by the developers? Why am I not surprised this might go wrong? Unless this goes wrong with our standard firmware, I'm not sure we should spend any more time on this. |
|
I don't blame you, I thought that it was understood from the first post that said he was putting into promiscuous mode that's what we were doing. Unless was are supposed to be able to put default firmware into monitor mode making the nexmon unnecessary. Thanks for your time and the command to force the wifi reload. -Chris |
|
I don't know why you would think it should have been understood - promiscuous mode is not the same as monitor mode. |
|
My mistake, I apologize.
From: Phil Elwell [mailto:[email protected]]
Sent: Tuesday, June 12, 2018 6:23 AM
To: raspberrypi/linux <[email protected]>
Cc: Chris Douglas <[email protected]>; Mention <[email protected]>
Subject: Re: [raspberrypi/linux] wlan freezes in raspberry pi 3B+ (#2453)
I don't know why you would think it should have been understood - promiscuous mode is not the same as monitor mode.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#2453 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGrL91R_VQ9jwYOM1WkEl-icoBhLME9Eks5t76SfgaJpZM4SwkCN>.
Click here<https://www.mailcontrol.com/sr/E8xEJgcIKGjGX2PQPOmvUp0m8S!KNwoj3Ra0zhZJ8qGVaGA06AtFwxmfWX1l6vtTJu!Oqka8PlqNc!rJiVGaJg==> to report this email as spam.
|
|
The OP might not be doing the same thing as I am with the nexmon fw since he is just trying promiscuous mode so it still might be something you can investigate for him. |
|
@pelwell @JamesH65 please don't give up on all of us who use the regular firmware... It is a real problem. In the following conditions, the firmware crashes several times per day:
Note: the raspberry PI wifi crashes randomly in any environment and also when running just as station (not AP). I'm just describing the conditions that increase the probability of crashing. |
|
Nobody's giving up. We have a number of difficult problems ongoing, and the Ethernet stalls are currently getting most of the attention, but now we have what should be a low-impact workaround for that the spotlight will turn to this issue (which looks suspiciously like an old Pi3B problem). |
|
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: |
|
It is nice to see those new versions... But are they stable ? Did anyone tested it for more then 2 hours ? (with a bridge like RaspAP) |
|
Hi.
But unfortunately the problem did not improve. I rebooted RPi at Jul 1 01:33:49. |
|
@hsjzmk - the one which you downloaded doesn't seem to have the potential fix. The firmware which @pelwell had provided was a test firmware. Please download the test firmware which is available in this comment - raspberrypi/firmware#1403 (comment) |
|
@frankweyns The test f/w provided by @pelwell back here #2453 (comment) has been running in AP mode (with bridging) continually for 20+ days just fine. I haven't tried the more recent one though. |
|
@ganeshs4 Thank you! I'll try this. |
|
My PI 3B+ is also having this issue. I grabbed the firmware mentioned here raspberrypi/firmware#1403 (comment) and here https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm. replaced the current file and rebooted. With 12 hours the problem occurred again. $ cat /proc/device-tree/model $ dmesg | grep "brcmfmac.*Firmware" Syslog when lockup occurred: Syslog when I restarted PI |
|
I have the same problem on a 3B $ cat /proc/device-tree/model $ dmesg | grep "brcmfmac.*Firmware" |
|
Same: |
|
I've got four pi's, three of which are having this issue. My home wireless is provided by an Orbi RBR20 mesh system running firmware 2.5.1.16 with about 25-30 clients on it. The only ones having issues are the pis. All the Pis having issues have this in common: dmesg | grep "brcmfmac.*Firmware" The pi not having issues is an older 3B running a different chip and firmware: BCM43430/1 wl0: Oct 22 2019 01:59:28 version 7.45.98.94 (r723000 CY) FWID 01-3b33decd Syslogs are all similar to this: |
|
Just posting this here for reference: It looks like a project that uses the Pi as an AP so that clients can connect and access educational material while offline. Anyhow, if I understand that table correctly, then it's almost like the last official firmware from Broadcom was rock solid (back in 2015) while every release since then from Cypress has crashed on them. As a result, it looks like they've reverted back to that original firmware for their project to get the stability/throughput that they need. It looks like version 7.45.18.0 from 2015 is the only one that didn't crash and can support 32 clients connected simultaneously to the Pi. Whereas every version from 7.45.132 in 2018 to 7.45.214 in 2020 all crash and support less clients. My own personal takeaway from this (not sure how accurate it is though), is that if you want a Pi 3B+/4 with stable WiFi then you need that original 7.45.18.0 firmware. If you want packet injection/monitor mode with nexmon for stable pen testing then you're out of luck at the moment with the built-in WiFi. I'm not sure, but my guess is that 7.45.18.0 doesn't support injection or monitor mode. From the table, the list of OSes that have 7.45.18.0: |
|
I have the same problem with my pi 3b+. With the firmware in raspian (Mar 23 2020 02:19:54 version 7.45.206 (r725000 CY)), the wifi freeze when traffic occurs. my wifi network used the same ssid for 2.4 and 5Ghz and i use a mesh. with the firmware from cypress the pi stuck on the mesh-master. with the firmware integrated in raspian or the older firmware from the .deb the pi switch directly to the better placed repeater pi runs on buster lite 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux greetings from germany |
|
Will these patches make it into a firmware build for the RPi 3 B models? |
|
is this still an issue? as iam running octoprint having following firmware: at 08:09 i powered on my printer and started the print.. and at 8:38 it lost the network connection! |
|
Same issue with a raspberry pi 4 and |
|
both Rpi4 and Rpi3 are seeing this issue now, and all software are up-to-date with "sudo apt upgrade" [ 13.011868] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1 my kernel is Linux RPi3-3 5.4.0-1032-raspi #35-Ubuntu SMP PREEMPT Fri Mar 19 20:56:57 UTC 2021 armv7l armv7l armv7l GNU/Linux Best, |
|
Very same issue here. Happened exactly after upgrading OctoPrint to version 1.6.0. Before everything worked fine. kernel version 5.10.17-v7+ Another instance running OctoPrint 1.5.3 and kernel version 4.19.118-v7+ works fine without these errors. |
|
Update: It's NOT a raspbian issue but a bug inside the latest OctoPrint plugin controlling the PSU via GPIO pins. This plugin itself contains an own GPIO plugin for compatibility reasons. But a bug inside that plugin breaks Wifi connections and produces all those error messages. Removing the GPIO plugin solves the problem. |
what todo? because i switched to klipper recently but still same octopi installation, just disabled all octoprint services (i think) and still getthe wifi outages after ah longer time of running... and the pi also keeps reachable on wifi when using the firmware from "2016" |
I don’t have that plug-in, the issue here is kernel related. |
|
Same problem here. After some time with enabled webcam ( = a lot of traffic) the wifi connection is lost. Not every time, but most time. After reboot of the Pi its works without problem. I have two RPi 3B+ who works as OctoPrint printserver. One had no issues, but the other had. The working one had an older OctoPi Image. If i switch the Hardware + SD card, the problems keeps the same on one device, whats shows thats a software related problem. Update to latest versions and disable power management doesn't help |
|
I am unable to connect to the Pi 4 after reboot. It happens also intermittently after a successful connection. Cannot ping, connect via ssh or http to the Pi. The Pi is able to ping out and connect to outside services. Connection is restored when I restart |
|
@ddacunha I can use wifi , now. and here is no problem. Edit Edit |
|
You are correct, once I turned off power management in |
I downgraded the firmware to 7.45.154 (/lib/firmware/brcm - my older Pi had these files) and disabled power management. Now, after two days of 8h printing each and enabled webcam no problems. With 7.45.229 and also disabled power management it freezes. The firmware files were the only thing I changed. Also interesting is that the older Pi had no entry in rc.local, but dmesg says power management is disabled and the newer image says it is enabled. |
|
Fyi for 43455-sdio fw there is 7.45.234 from Cypress I found from their v5.10.9-2021_1020 FMAC package I'm running on some stability tests atm. |
and others
(see also #1342 )
I've also got that problem with wifi dying.
This is with 4.14.27-v7+ and with
/sbin/iw dev wlan0 set power_save off
/sbin/ifconfig wlan0 promisc
in /etc/rc.local.
The text was updated successfully, but these errors were encountered: