-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
nexmon blindness bug (brcmf_cfg80211_nexmon_set_channel) #267
Comments
cc @hexwaxwing |
docs added https://pwnagotchi.ai/usage/#known-issues |
You could try reloading the driver instead of rebooting the pi, using :
If this still fails, then a reboot will fix this. |
tried that way, it doesn't always work, the only reliable way is rebooting |
So, The Nexmon firmware is a little picky on how its interfaced, How are your bringing up the mon interface in linux before bettercap gets to it? |
iw phy phy0 interface add mon0 type monitor && ifconfig mon0 up |
(from re4son monstart script) |
I just noticed on the Nexmon Repo that the bcm43455c0 does not support wifi frame injection. That might be the reason for the drivers crashing as they are not handling the requests to do frame injection correctly from bettercap. |
Ok, So I looked, We are using the older version of the firmware provided by Nexmon, I think Re4son kernel does it as its the default for Nexmon to use that. Patches and Commits from the Nexmon Project show 7.45.189 as the latest version you can use (The base firmware comes from the OEM, not the RPI foundation) as of RC4, we are using version 7.45.154 of the bcm43455c0 firmware This issue should only affect 3B+ and 4s, the 3B and the 0W use the same wifi chip and are listed as supporting injection. |
More Details, I've looked into how the Re4son kernel builder pulls down its firmware, its even /worse/ Looks like it pulls from https://github.com/Re4son/re4son-nexmon as its source of nexmon patches... its years out of date. I'm doing some prototyping to update this now. |
Good News, The Nexmon Patches with the stock kernel works well, Here is my DMesg output after running for 10 minutes, I will be running it for the next 24 hours to see if its stable,
Here is my uname
|
And I failed, You get a little more debug output this time overall..
Edit: |
yep when that happens even trying to change channel manually doesn't work, i think it's the heat |
Based off this photo, There is no TIM under the wifi can at all... Since its used for shielding RF, this is of no surprise. Someone should get a IR Camera on the board and take a look. Also You notice that White IC in the top left, Thats the same chip they used to show people the SuperMicro Implant... lulz |
So, I'm looking at the datasheet, for the CYW43455 It states that the Max temp for operation is 120C while under normal loads on a 4 layer board Of course Max oper temp is +85C The thing only puts out 1.2W but I did notice that on the older RPI0W Chips it had a self limiter for overheat, This one is not stated in the data sheet as having one |
so you're saying that it's the chinese sabotaging our wifi pwning, right? |
Maybe.... Until I can get a proper Temp readout of the die itself while under the heavy load, We wont know. |
By default airodump hops every 250ms, so the only difference that comes to my mind is that you do it through wext, while airodump uses (AFAIK) nl. |
@DrSchottky yes i think it's not the timing but the methodology ... i also don't think airodump uses calls to the iwconfig binary as i do in bettercap, pretty sure there's a cleaner way to do it :D |
@evilsocket exactly, it uses a totally different software stack (wext vs nl80211). |
@andrewbeard any news? |
I get the "brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=4109, -110" errors after about an hour when I have bluetooth enabled in the config, but bluetooth does not connect for whatever reason. pi0w, temp shows as 41c. pwnagotchi process locks and goes defunct when this happens. Is this the same bug? Edit: Just saw the link to #494 |
I got it "working" by writing a little script that reloads the driver everytime it crashes |
do you mind posting your script? "modprobe -r brcmfmac && modprobe brcmfmac && sleep 2 && /usr/bin/monstart && systemctl restart pwnagotchi" for the driver reload seems to kinda work some of the time for me but not always. wondering if you're doing something better. |
echo -n "mmc1:0001:1" > /sys/bus/sdio/drivers/brcmfmac/unbind echo -n "mmc1:0001:1" > /sys/bus/sdio/drivers/brcmfmac/bind this is working for me |
are you running this while pwnagotchi service is still running? are you doing anything more than the driver un/binding like trying to add mon0 back or bring it up? and are you monitoring dmesg for brcmf_cfg80211_nexmon_set_channel errors to trigger it? because it doesn't look like mon0 is brought back up after the binds and trying to "/usr/bin/monstart" or "iw phy phy0 interface add mon0 type monitor && ifconfig mon0 up" gives a "command failed: No such file or directory (-2)" error for me. |
ah, the error is because phy0 doesn't exist. when you rebind the driver, it increments the phy instance, so phy1, phy2 instead of phy0. this command seems to be more consistent (though I don't know if functionally it's any different): "iw dev wlan0 interface add mon0 type monitor && ifconfig mon0 up" |
here's my nexmon blindness error watchdog script I whipped together that seems to work pretty well until the bug is fixed. needs to be run as root. seems to do its job from the testing I've done:
|
workaround for evilsocket/pwnagotchi#267
I just read through this thread I was confident @DrSchottky and @andrewbeard where on to something. |
@myusuf3 I never heard anything back. |
Seems like there is a fix available (raspberrypi/linux#2453) ...trying this right now |
not working, but there've been some kernel updates. I'll try them |
any updates guys? facing similar issues on RPi0w.
airodum has not picked up anything so far, and the bug happens right away for me. The people from pwnagotchi managed to get it working, I should be able to get better results, there must be something I'm missing here I switched to the firmware ("latest"?) provided by cypress (sdio.bin..) from the .tar.gz someone uploaded here, did not improve things, did not make it worse either I'm using the module from DrShottsky's fork (4.19), here's the log when module is registered or manually inserted dmesg | grep brcm iwconfig wlan0 wlan0 IEEE 802.11 Mode:Monitor Frequency:2.412 GHz Tx-Power=31 dBm iwconfig wlan0 power off |
For the Pi 4, could the latest nexmon firmware fix this issue? |
Any Update? I'm facing the same problem reproducing it 100% consitent. It seems that this bug is still not fixed and still persistent in the latest Kali Linux for ARM builds for the Raspberry Pi. |
@NetherStar64 this is a nexmon bug, you're asking for updates in the wrong repo :) |
Oh ok sorry. |
@NetherStar64 if you can reproduce the issue I can spare a few hours trying to debug it. |
@DrSchottky Yes I really would like to help you. Where can I contact you? |
@NetherStar64 Twitter, Telegram or Discord(DrSchottky#4172) |
Could the AI be used to figure out how this bug is triggered and avoid it in the future? It will require faster detection of the bug. E.g. by checking which channel the wifi is on every time after changing it, to detect the moment a change fails. Useful functions for this can be found in the source for aircrack-ng in src/osdep/linux.c. The trigger could be anything from receiving a bad packet to sending packages to fast or slow or issues related to the package size or combinations of packages with different size. |
I think an AI would be pretty overkill for this Bug. In
seemoo-lab/nexmon#335 (comment)
there's already a proposed Patch that fixes the Crash 99% of the time, but
it still crashes about ~30-60min while constantly injecting Packets.
sturles <[email protected]> schrieb am Di., 2. Feb. 2021, 16:41:
… Could the AI be used to figure out how this bug is triggered and avoid it
in the future?
It will require faster detection of the bug. E.g. by checking which
channel the wifi is on every time after changing it, to detect the moment a
change fails. Useful functions for this can be found in the source for
aircrack-ng in src/osdep/linux.c.
The trigger could be anything from receiving a bad packet to sending
packages to fast or slow or issues related to the package size or
combinations of packages with different size.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#267 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APEXFJXF3XUXLMVVHHK6TNDS5AMJXANCNFSM4JADVA7A>
.
|
Hey guys, I'm new here. I checked an nexmon GitHub page, and in compatibility it says, that frame injection is supported for raspi4 on raspberry pi os (kerner 5.4 and above), not Raspbian. I'll try to install pwnagotchi on rpios in couple of days, and get back to you. |
Any solutions or workarounds that can be implemented? |
I do not think this is an issue anymore. I see these entries in my log (e.g., brcmfmac: brcmf_cfg80211_nexmon_set_channel: Set Channel failed: chspec=4099, -110) and yet my pwnagotchi is still capturing packets successfully if I just let it run. I also monitor the ai observations and as long as those are not blank for any given epoch (unless you're out in the middle of nowhere), it seems like you can ignore these errors. I turned off the watchdog plugin on mine because it was needlessly reboot the pwnagocthi. |
every once in a while, nexmon dies with:
And only a reboot can fix the wifi, this is why the
mon_max_blind_epochs
parameter exists, to reboot the board when this happens.Ideally we should document this known issue, the configuration and some day maybe fix it.
The text was updated successfully, but these errors were encountered: