-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BCM43455C0: firmware has halted or crashed #595
Comments
All I can see from that log is that a virtual monitor interface was added and then there were 7 more tries to add another one, which is not supported, only a single virtual monitor interface per interface can exist. Then the chip crashes and is restarted. Can you provide me with the commands that you executed during this? Best would be everything that I need to replicate this behavior. Including OS info, kernel, driver version... |
RaspiOS 64bit lite Bookworm, using nexmon 7.45.206 for bcm43455c0 from DrSchottky his repo. I am running Pwnagotchi, which uses a plugin to check journalctl for erros on the wifi firmware.
You may not believe it, but when it sees a lot of accesspoints or quick injecting of packets it seems to crash. The monitor adding and firmware crash are not related, there is about 150 seconds inbetween. That's because of me restarting the services, hence the error about already a monitoring device. |
The command used to start monitor mode: start_monitor_interface() {
rfkill unblock all
ifconfig wlan0 up
sleep 3
iw dev wlan0 set power_save off
iw phy "$(iw phy | head -1 | cut -d" " -f2)" interface add wlan0mon type monitor
sleep 2
rfkill unblock all
ifconfig wlan0 down
ifconfig wlan0mon up
iw dev wlan0mon set power_save off
} The sleep command is needed, because on the RPi zero2w the firmware will crash immediately if we do not delay start monitor mode. |
If you are using @DrSchottky's version, you might want to ask there instead. |
|
@jlinktu Of course I also tried with your repository. I had to alter the installation a bit to use libmpfr-6.2.0 and libisl-23.2.0.
|
Leads me to think that the injection of the deauth frame kills the chip. |
That could surely be, although it had done some deauthing already prior to that part. Here's the rest right before the snip.
|
Please load the |
How do I do that exactly? |
Add Or if you want to do it manually (assuming you've already build
|
I don't know if this is the more verbose debug you expected:
|
Please provide the related output of |
|
Check if debug output is set with |
Doesnt seem like it sudo cat /sys/module/brcmfmac/parameters/debug |
Any error or warning when you ran |
Let's try to add even more output with: |
yeah thats working, ill run depmod -a and reboot and let it run until crash okay? |
When you reboot, the non-nexmon kernel module will be loaded and the debug parameter will also be discarded. Thus, you will need to run |
okay its running, itll be about 5-10 minutes |
No crash as far as I can see. |
no, my bad. service for scanning wasnt runing LOL |
|
The actual message of the crash found
|
I trust you experts in this know what you are talking about, I don't even know if it's a nexmon bug or something that my software is doing wrong. Heck, for all I know it's an issue in the original part of the firmware. |
@DrSchottky already pointed out the correct location of where the crash occurs. |
I am happy to test any patches you can think of! |
Can you please replace
Same if you experience a crash + then the |
This is the log from right after these deauth frames on channel 11
No crash yet, I am waiting for that to happen. I will post with an extra log if that happens. |
Crashlog:
Took well over 10 minutes, instead of about 3 minutes yesterday. |
@jlinktu isn't there an UaF in your patch? |
What is an UaF? |
If scb is null p memory is being freed, but it's still passed to wlc_sendctl. Shouldn't sendframe immediately return after calling pkt_buf_free_skb? |
Ah sorry, brainlag, use after free.. |
@jayofelony please try again with |
get this error straight away after running |
I will try to replicate your setup tomorrow to debug that, otherwise this creates too much overhead. |
You can use this image. It's exactly what I use.
|
This can be used to reproduce the issue, I run it for 30s and got the crash
|
Any update on this, need me to test something? |
No, just didn't find time to check yet. |
Checking back on this. Now that kernel 6.6 is out, is there much difference between the workings of a 64bit firmware vs 32bit? I suspect there will also be new version for the bcm43455c0, bcm434340/bcm43436 chipsets. Would it be an idea to update nexmon to the latest version now that many new version have been released in the meantime? |
The firmware blob is loaded onto the WiFi chip's ARM Cortex processor and is therefore independent of the hosts architecture, and also mostly independent of the kernel version (neglecting that driver and firmware need some sort of compatibility). |
Output from
journalctl
:Feb 01 10:33:10 jayofelony kernel: ieee80211 phy0: brcmf_fw_crashed: Firmware has halted or crashed
Device:
Raspberry Pi 4
WiFi chip:
43455c0
Firmware:
nexmon 7.45.206
The text was updated successfully, but these errors were encountered: