search

morrownr / USB-WiFi

USB WiFi Adapter Information for Linux
2.4k stars 161 forks source link

MT7610U weird Active monitor mode behaviour on Raspberry Pi #379

Open LightMoon opened 4 months ago

LightMoon commented 4 months ago

Hi! I am facing a strange issue with AWUS036ACHM - Chipset MT7610U on Kali Linux RasPi 5. The card stops working and throwing ioctl(SIOCGIFINDEX) failed: No such device error if you run Aireplay-ng while having Airodump-ng running.

Error on shown on airodump-ng

read failed: Network is down                                                                         
Interface wlan1mon:                                                                                  
ioctl(SIOCGIFINDEX) failed: No such device                                                           
Can't reopen wlan1mon

Error on shown on aireplay-ng

NB: this attack is more effective when targeting
a connected wireless client (-c <client's mac>).
12:30:31  Sending DeAuth (code 7) to broadcast -- BSSID: [A0:04:60:xx:xx:xx]
12:30:32  Sending DeAuth (code 7) to broadcast -- BSSID: [A0:04:60:xx:xx:xx]
write failed: Network is down
wi_write(): Network is down

Good to note, I did ran airmon-ng check kill prior to eliminate processes interference, also replaced the driver to the latest, however, none has stopped the issue.

uname -a Linux kali-raspberry-pi5 6.1.64-v8+ #1 SMP PREEMPT Sun Dec 3 11:34:54 UTC 2023 aarch64 GNU/Linux It seems the issue is related to arm CPUs as it can be reproduced on the latest Raspbian OS; although the card on Kali (Intel) works fine. I am not sure but if someone could confirm this issue could be related to the bug - https://bugzilla.kernel.org/show_bug.cgi?id=217465 would be great. I would appreciate any tips you could give me in getting the card to the usable stage.

Steps for reproducing error in summary:

@https://github.com/morrownr/88x2bu-20210702/issues/208

morrownr commented 4 months ago

Kali Linux for RasPi => apt update & apt upgrade -y

You said you are seeing the same thing on RasPiOS so I will test with my RasPi4B and RasPiOS 2023-12-06.

replace the existing MT7601U driver with the latest version from the Linux kernel repository and the reboot once.

I am not following this. Do you mean to say MT7610u? And I could use a further explanation about replacing the latest version of the driver. Are you actually talking about the firmware file?

airmon-ng check kill

I haven't used that in a long time. My experience is that it does not work well. I wrote a replacement:

https://github.com/morrownr/Monitor_Mode

The primary difference is that my scripts pause the processes instead of trying to kill them. Many of the procs have code to detect when they are going down and will spawn another process. airmon-ng does not handle that very well. On the other hand, if you pause the procs, nothing triggers another process but the process is frozen and can't cause problems.

I can handle the rest of the checklist but can I get you to clarify the questions I asked and can I get you to try start-mon.sh?

FYI: That RasPi version of Kali does not have a very good track record.

@morrownr

LightMoon commented 4 months ago

I am not following this. Do you mean to say MT7610u? And I could use a further explanation about replacing the latest version of the driver. Are you actually talking about the firmware file?

I mean replacing the firmware file with latest per this guideline - Firmware - How to install firmware for Mediatek-based (and RTW88) USB WiFi adapters

I can confirm the result is the same with using ./start-mon.sh on RasPi version of Kali & RasPi. RasPi - Linux raspberrypi 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux 

root@raspberrypi:~# ethtool -i wlan1
driver: mt76x0u
version: 6.1.0-rpi8-rpi-2712
firmware-version: N/A
expansion-rom-version: 
bus-info: 1-1.1:1.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
morrownr commented 4 months ago

I have plugged my ACHM into my Pi4B and checked things to a certain point. An interface comes up as expected:

$ iw dev
phy#1
    Interface wlan1
        ifindex 5
        wdev 0x100000001
        addr 00:c0:ca:ad:4b:cc
        type managed
        txpower 0.00 dBm
        multicast TXQ:
            qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes    tx-packets
            0   0   0   0   0   0   0   0       0

In rereading your first post, it was not clear to me that you established that an interface was available. Would you mind rebooting and doing the following: (post the results)

$ iw dev post result $ airmon-ng check kill post result $ iw dev post result $ airmon-ng start wlanX ( x could be different to your environment ) post result

I will do the same depending on your results.

It seems the issue is related to arm CPUs as it can be reproduced on the latest Raspbian OS; although the card on Kali (Intel) works fine.

The thing that I am pondering right now is not so much that the problem is showing on arm CPU's as it is showing on the RasPi5B. While I don't have a RasPi5B, I think I read where it seems some changes have been made to the USB subsystem (thank goodness). I don't know if the changes are good or bad. If I see good results with the same RasPiOS that you are using, then that tends to support the idea that the issue is in the RasPi5B.

FYI: The driver and firmware for the mt7610u chipset are very stable and have been for a few years so they would be very far down my list of things that could be causing the problem.

@morrownr

LightMoon commented 4 months ago

here is the results with same sequence that you asked for but please have that in mind the issue only occur when running airodump-ng (fixed on a channel) and aireplay-ng at the same time.

This is the sequence I followed airodump-ng --channel 11 --bssid xx:xx:xx:xx:xx:xx wlanXmon aireplay-ng -0 10 -a xx:xx:xx:xx:xx:xx wlanXmon

iw dev

└─# iw dev
phy#1
        Interface wlan1
                ifindex 4
                wdev 0x100000001
                addr ae:aa:37:63:1e:86
                type managed                                                                        
                txpower 1.00 dBm                                                                    
                multicast TXQ:                                                                      
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0

airmon-ng check kill

└─# airmon-ng check kill

Killing these processes:

    PID Name
    616 wpa_supplicant

iw dev

└─# iw dev
phy#1
        Interface wlan1
                ifindex 4
                wdev 0x100000001
                addr 00:c0:ca:b3:ff:c7
                type managed
                txpower 1.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       0       0       0       0       0       0               0

airmon-ng start wlan1

 airmon-ng start wlan1

PHY     Interface       Driver          Chipset

phy0    wlan0           brcmfmac        Broadcom 43455
phy1    wlan1           mt76x0u         MediaTek Inc. WiFi
                (mac80211 monitor mode vif enabled for [phy1]wlan1 on [phy1]wlan1mon)
                (mac80211 station mode vif disabled for [phy1]wlan1)

iw list [after enabling monitor mode]

└─# iw dev
phy#1
        Interface wlan1mon
                ifindex 5
                wdev 0x100000002
                addr 00:c0:ca:b3:ff:c7
                type monitor
                channel 10 (2457 MHz), width: 20 MHz (no HT), center1: 2457 MHz
                txpower 2.00 dBm

comparing the results with yours, txpower is different. Is this expected?

LightMoon commented 4 months ago

@morrownr Just checking if you have all the information you asked for?