search

seemoo-lab / nexmon

The C-based Firmware Patching Framework for Broadcom/Cypress WiFi Chips that enables Monitor Mode, Frame Injection and much more
GNU General Public License v3.0
2.39k stars 448 forks source link

Rpi 3B+ - Not stable for 5G channel #234

Open leonzhang1109 opened 6 years ago

leonzhang1109 commented 6 years ago

When using airodump-ng with Nexmon driver on RPI 3B+, It only works few minutes when monitor 5G channel. airmon-ng start wlan0 airodump-ng --channel 149 wlan0mon

amcewen commented 5 years ago

I think I'm seeing this problem too. Definitely getting it hanging after a few minutes when I'm capturing traffic in promiscuous mode, and there's a 5G network here.

Do you get any errors in dmesg? I see an unknown mailbox data error, and then it leaves promiscuous mode (and seems to need a reboot to get working again):

brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012

Any suggestions for things I could try? I'm happy to spend some time tweaking code, rebuilding and testing, but it's tricky to know what to look at. Turning on more debugging, nothing leaps out at me, but I figured I'd post it in case it's any help.

...
[  354.760347] brcmfmac: brcmf_sdio_hostmail Dongle ready, protocol version 4
[  354.760351] brcmfmac: brcmf_sdio_bus_sleep Enter: request WAKE currently WAKE
[  354.760353] brcmfmac: brcmf_sdio_clkctl Enter
[  354.760356] brcmfmac: brcmf_sdio_bus_sleep new state WAKE
[  354.760359] brcmfmac: brcmf_sdio_bus_sleep Exit: err=0
[  354.760366] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000a, nbytes=1
[  354.760384] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000b, nbytes=1
[  354.760404] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000c, nbytes=1
[  354.760423] brcmfmac: brcmf_sdiod_ramrw read 4 bytes at offset 0x00007ffc in window 0x00258000
[  354.760452] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000a, nbytes=1
[  354.760470] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000b, nbytes=1
[  354.760488] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000c, nbytes=1
[  354.760505] brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x001FF350
[  354.760510] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000a, nbytes=1
[  354.760528] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000b, nbytes=1
[  354.760545] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000c, nbytes=1
[  354.760564] brcmfmac: brcmf_sdiod_ramrw read 64 bytes at offset 0x00007350 in window 0x001f8000
[  354.760593] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000a, nbytes=1
[  354.760611] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000b, nbytes=1
[  354.760629] brcmfmac: brcmf_sdiod_request_data rw=1, func=1, addr=0x1000c, nbytes=1
[  354.760647] brcmfmac: brcmf_sdio_hostmail: Unexpected mailbox data content: 0x40012
[  354.772394] brcmfmac: brcmf_sdio_bus_watchdog Enter
[  354.792390] brcmfmac: brcmf_sdio_bus_watchdog Enter
...
ghost commented 5 years ago

Someone mentioned something about a " 5G patch to fix the reboot problem" Either in the nexmon github issues or the Kali nethunter.The patch works on both arm chroot and pi.

kimocoder commented 5 years ago

It was a kernel pushed to NetHunter repo that fixed the reboot issue. I can see if I may find it again. Remembered the commit, cause I know it's been a problem for some time now

kimocoder commented 5 years ago

And here you go, seems like it's not a patches readable, but a module/patch added to kernel before it was built.

You may ask the developer what the steps is to accomplish this