mt7921u active monitor mode breaks driver

[ZerBea]

I got an ALFA AWUS036AXML. Setting active monitor mode causes the driver to stop.
It took me several days to figure out what went wrong. A lot of tests have let this thread grow.
This is the conclusion (the entire history is below).

Steps to reproduce by common tools like iw, ip link and tshark.

monitor mode:

$ sudo ip link set wlp22s0f0u4i3 down
$ sudo iw dev wlp22s0f0u4i3 set type monitor
$ sudo ip link set wlp22s0f0u4i3 up
$ tshark -i wlp22s0f0u4i3
22 packets captured

active monitor mode:

$ sudo ip link set wlp22s0f0u4i3 down
$ sudo iw dev wlp22s0f0u4i3 set monitor active
$ sudo ip link set wlp22s0f0u4i3 up 
$ tshark -i wlp22s0f0u4i3
Capturing on 'wlp22s0f0u4i3'
^C
0 packets captured

Background:
Running active monitor mode, the device ACK incoming frames addressed to the virtual MAC of the device.
This feature is really useful to perform PMKID attacks.
At the moment, active monitor mode is working on:

mt76x0u
mt76x2u

It is not working on:

mt7601u
mt7921u

I see three options:

hcxdumptool does not set active monitor mode by default even if the driver reports that it is supported.
That has been done by this commit:
ZerBea/hcxdumptool@8d3f24e

active monitor mode capability should not be reported by the driver
[code]
mt7601u:
$ iw list | grep active
Device supports active monitor (which will ACK incoming frames)

mt7921u:
$ iw list | grep active
Device supports active monitor (which will ACK incoming frames)
[/code]

active monitor mode should be fixed by driver

[ZerBea]

Looks like this driver (https://github.com/openwrt/mt76) doesn't compile (out of the box) running Linux 6.6.1:

$ make -C /lib/modules/`uname -r`/build M=$PWD
make: Entering directory '/usr/lib/modules/6.6.1-arch1-1/build'
  CC [M]  /tmp/mt76/mmio.o
In file included from /tmp/mt76/mt76.h:19,
                 from /tmp/mt76/mmio.c:6:
/tmp/mt76/testmode.h:196:32: error: array type has incomplete element type 'struct nla_policy'
  196 | extern const struct nla_policy mt76_tm_policy[NUM_MT76_TM_ATTRS];
      |                                ^~~~~~~~~~~~~~
/tmp/mt76/mt76.h: In function 'mt76_put_page_pool_buf':
/tmp/mt76/mt76.h:1647:9: error: implicit declaration of function 'page_pool_put_full_page' [-Werror=implicit-function-declaration]
 1647 |         page_pool_put_full_page(page->pp, page, allow_direct);
      |         ^~~~~~~~~~~~~~~~~~~~~~~
/tmp/mt76/mt76.h: In function 'mt76_get_page_pool_buf':
/tmp/mt76/mt76.h:1655:16: error: implicit declaration of function 'page_pool_dev_alloc_frag' [-Werror=implicit-function-declaration]
 1655 |         page = page_pool_dev_alloc_frag(q->page_pool, offset, size);
      |                ^~~~~~~~~~~~~~~~~~~~~~~~
/tmp/mt76/mt76.h:1655:14: error: assignment to 'struct page *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
 1655 |         page = page_pool_dev_alloc_frag(q->page_pool, offset, size);
      |              ^
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:243: /tmp/mt76/mmio.o] Error 1
make[1]: *** [/usr/lib/modules/6.6.1-arch1-1/build/Makefile:1913: /tmp/mt76] Error 2
make: *** [Makefile:234: __sub-make] Error 2
make: Leaving directory '/usr/lib/modules/6.6.1-arch1-1/build'

[ZerBea]

BTW:
I went back
to kernel 6.5.1 (Debian kernel config) -> neither monitor mode nor packet injection is working
to kernel 6.1.21 (Raspbian kernel config) -> neither monitor mode nor packet injection is working

[ZerBea]

update
After I got this issue report:
ZerBea/hcxdumptool#376
I did some more tests.
If the interface is on monitor mode:

$ sudo hcxdumptool -m wlp22s0f0u9u3i3
$ iw dev
phy#12
	Interface wlp22s0f0u9u3i3
		ifindex 15
		wdev 0xc00000001
		addr 00:c0:ca:b5:74:e6
		type monitor
		channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
		txpower 3.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	

it will receive packets:

$ tshark -i wlp22s0f0u9u3i3
Capturing on 'wlp22s0f0u9u3i3'
263 packets captured

But once the first frame has been injected, every thing stops:

$ tshark -i wlp22s0f0u9u3i3
Capturing on 'wlp22s0f0u9u3i3'
^C
0 packets captured

Looks like frame injection killed the driver.

[morrownr]

@ZerBea

You might want to retest with the recently released firmware:

https://github.com/morrownr/USB-WiFi/blob/main/home/How_to_Install_Firmware_for_Mediatek_based_USB_WiFi_adapters.md

Section 2.

[ZerBea]

@morrownr

Thanks for that information. I'll give it a try, but I still think it is related to the driver.

[ZerBea]

This is the latest working firmware:
Build Time: 20230526130958

This one does not load:
Build Time: 20231109190918

[morrownr]

This one does not load: Build Time: 20231109190918

It loads here:

$ ethtool -i wlx00c0cab37abb
driver: mt7921u
version: 6.5.0-0.deb12.1-amd64
firmware-version: ____010000-20231109190959

Adapter: Alfa AXML
Distro: Debian 12

Remember that wifi firmware for the 7921 requires two firmware files:

WIFI_MT7961_patch_mcu_1_2_hdr.bin
WIFI_RAM_CODE_MT7961_1.bin

There is also a bluetooth file but you won't be using it to so you can delete the file from the system:

BT_RAM_CODE_MT7961_1_2_hdr.bin

[ZerBea]

I double checked this:

old firmware:

[16148.856186] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20230526131214
[16148.879434] mt7921u 1-9.3:1.3: HW/SW Version: 0x8a108a10, Build Time: 20230526130917a

new firmware:

[41144.190166] usb 1-9.3: new high-speed USB device number 11 using xhci_hcd
[41144.321418] usb 1-9.3: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[41144.321422] usb 1-9.3: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[41144.321424] usb 1-9.3: Product: Wireless_Device
[41144.321426] usb 1-9.3: Manufacturer: MediaTek Inc.
[41144.321427] usb 1-9.3: SerialNumber: 000000000
[41144.428601] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20231109191416

only the BT firmware has been loaded.

$ iw dev
$

All three bin's have been replaced:

$ ls *MT7961*.*
BT_RAM_CODE_MT7961_1_2_hdr.bin.zst
WIFI_RAM_CODE_MT7961_1.bin.zst
WIFI_MT7961_patch_mcu_1_2_hdr.bin.zst

I give it another try without compressing the files.

[41864.599670] usb 1-9.3: USB disconnect, device number 16
[41868.761868] usb 1-9.3: new high-speed USB device number 17 using xhci_hcd
[41868.893554] usb 1-9.3: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[41868.893561] usb 1-9.3: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[41868.893563] usb 1-9.3: Product: Wireless_Device
[41868.893565] usb 1-9.3: Manufacturer: MediaTek Inc.
[41868.893567] usb 1-9.3: SerialNumber: 000000000
[41869.006650] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20231109191416

same result.

BTW:
regardless if the new firmware has been compressed by zstd and regardless to which port the device is connected (USB2 or USB3) after a while a got this error:

connected to USB2 port
[41930.422262] usb 1-9.3: device not accepting address 17, error -71
connected to USB3 port
[41961.868976] usb 1-4: device descriptor read/64, error -110

I'm on kernel

$ uname -r
6.6.3-arch1-1

[morrownr]

$ uname -r
6.5.0-0.deb12.1-amd64

I haven't gone to kernel 6.6 yet on this system, which is my main dev box, but will investigate doing a test with 6.6 on another box.

Keep in mind that loading the bluetooth firmware is basically worthless as you can't run USB3 and bluetooth together on a USB WiFi adapter. I'm pretty sure the communications between Mediatek and the makers was poor in this respect as the bt firmware should not be loaded if the adapter is in USB3 mode.

[ZerBea]

At the moment, I'm running out of ideas.

[morrownr]

I got nothing. I've never seen firmware compressed but if you say it works, it probably works. Got any other distros to try?

[ZerBea]

zstd compression is not something new:
https://www.phoronix.com/news/2021-Linux-Zstd-Firmware
and it is working like a charm.

BTW:
At every test my reference is an ALFA AWUS036ACM (mt76x2u) and an ALFA AWUS036ACHM (mt76x0u).
If both devices/drivers are working as expected, everything seems to be fine.
After that, I'll go hunting for the problems of the new device/driver.

[morrownr]

I wonder if you had a bad download of one of the wifi firmware files?

[ZerBea]

Good point - let's compare it:
$ md5sum BT_RAM_CODE_MT7961_1_2_hdr.bin
f8e386541ca02a6311d7c0d9441fbab7 BT_RAM_CODE_MT7961_1_2_hdr.bin

$ md5sum WIFI_MT7961_patch_mcu_1_2_hdr.bin
0a4d833efe94a56c502de8a38405d8fe WIFI_MT7961_patch_mcu_1_2_hdr.bin

$ md5sum WIFI_RAM_CODE_MT7961_1.bin
8d0a4f6dc2d01a8b442ae0b8d76d9122 WIFI_RAM_CODE_MT7961_1.bin

[morrownr]

Here are my results from /lib/firmware/mediatek

$ md5sum WIFI_MT7961_patch_mcu_1_2_hdr.bin
0a4d833efe94a56c502de8a38405d8fe WIFI_MT7961_patch_mcu_1_2_hdr.bin

$ md5sum WIFI_RAM_CODE_MT7961_1.bin
8d0a4f6dc2d01a8b442ae0b8d76d9122 WIFI_RAM_CODE_MT7961_1.bin

I can't check the BT firmware because it does not exist on my system. I delete it to prevent it from loading and using resources. It should not load given that BT is turned off in our adapters (Alfa AXML) but it does... that is a programming mistake that needs to be corrected.

[ZerBea]

Thanks. The md5 hashes matches.
I'll compile kernel 6.5 and give it another try.

[morrownr]

Alright @ZerBea , you know better than to change 2 variables at the same time.

[ZerBea]

Unfortunately the system on which I compiled the kernel does not have USB3 hardware.
Now compiling the kernel on an USB3 system. When finished, we have all combinations of kernels, ehci, xhci and firmware.

Conclusion:
the new firmware loads fine on kernel 6.5

the ERROR is back (after a while):
[ 4213.904348] usb 1-2: device not accepting address 21, error -71

and packet injection is still not working.

[ZerBea]

As a final test I compiled kernel 6.1 and got the same results.
Now I give up and wait for a driver update.

[ZerBea]

To make sure it is not a malfunction of my device. Is packet injection working on your system (kernel 6.5 and latest firmware)?
$ sudo hcxdumptool -i INTERFACENAME --rds=1 -F
I guess that my device is fine, because the problem occurs on openwrt as well.
ZerBea/hcxdumptool#376

[morrownr]

Interesting. It looks to me that you have the makings of additional bugs reports. It is also possible there is one source that is the cause. Hard to say.

The USB subsystem drivers, and especially the USB3 drivers, are not mankind's great invention.

I'm going to try to setup to test with kernel 6.6 and 6.7 tomorrow if I feel better.

I have two test systems in my lab but only one is setup and it is using secure boot which is not going to work with this very well at all so I need to rethink my setup. Will report.

[ZerBea]

Great, thanks.
My test systems:
2 x Intel (ehci)
2 x AMD (xhci)
5 x Raspberry Pi zero
2 x Raspberry Pi A
2 x Raspberry Pi B

Linux kernel 6.1, 6.5 and 6.6

All tested devices / drivers (the latest tested device only with a driver patch) passed the tests on all systems:
ZerBea/hcxdumptool#361
Except the mt7921u, which suggests to me that my testing environment is ok,
Unfortunately the mt7921u test is time expensive, because, in every case I have two remaining screws (driver and firmware).
Right know, I don't know which of them caused the trouble.

[ZerBea]

I found the problem.
Unfortunately it is similar to this one:
#778

Driver reports that active monitor mode is possible:

$ iw list | grep active
	Device supports active monitor (which will ACK incoming frames)

But if hcxdumptool set active monitor mode, it stops working.

If active monitor mode is disabled, everything's fine

0 ERROR(s) during runtime
638 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
83 EPB written to pcapng dumpfile

exit on sigterm

I don't think the problem is related to hcxdumptool, because it can be reproduced with iw, ip link and tshark, too:

$ sudo ip link set wlp22s0f0u4i3 down
$ sudo iw dev wlp22s0f0u4i3 set type monitor
$ sudo ip link set wlp22s0f0u4i3 up
$ tsahrk -i wlp22s0f0u4i3
22 packets captured

$ sudo ip link set wlp22s0f0u4i3 down
$ sudo iw dev wlp22s0f0u4i3 set monitor active
$ sudo ip link set wlp22s0f0u4i3 up 
$ tshark -i wlp22s0f0u4i3
Capturing on 'wlp22s0f0u4i3'
^C
0 packets captured

[morrownr]

Have you modified the original message to reflect this finding?

How does this finding reflect overall? Is packet injection working with active monitor mode off?

I'm a little fuzzy after being sick for so many days. Why is active monitor mode needed?

[ZerBea]

The head line has been modified.

Packet injection is working like a charm:
ZerBea/hcxdumptool#361 (comment)

Background:
Running active monitor mode, the device ACK incoming frames addressed to the virtual MAC of the device.
This feature is really useful to perform PMKID attacks.
At the moment, active monitor mode is working on:

mt76x0u
mt76x2u

It is not working on:

mt7601u
mt7921u

I see three options:

hcxdumptool does not set active monitor mode by default even if the driver reports that it is supported.
That has been done by this commit:
ZerBea/hcxdumptool@8d3f24e

active monitor mode capability should not be reported by the driver
[code]
mt7601u:
$ iw list | grep active
Device supports active monitor (which will ACK incoming frames)

mt7921u:
$ iw list | grep active
Device supports active monitor (which will ACK incoming frames)
[/code]

active monitor mode should be fixed by driver

[morrownr]

The head line has been modified.

It might help since this post has followed a long path to get where it is, if you use "Edit:" at the top of the original post then add what you have added in your last 2 posts so as to make it easy for a person that might fix it to understand without having to track things down. It might also, as am alternative work if you close this report and start a clean new post. I'm going to try to consolidate the information and add it to my main mt7921u bug list at my site. It seems quite clear at this point that active monitor is broken and is the cause of the problem at this point.

@morrownr

[ZerBea]

Kernel 5.15 and 6.1 - not working out of the box as expected:

[   19.385811] usb 3-2: new high-speed USB device number 3 using xhci_hcd
[   19.529178] usb 3-2: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[   19.529189] usb 3-2: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[   19.529193] usb 3-2: Product: Wireless_Device
[   19.529196] usb 3-2: Manufacturer: MediaTek Inc.
[   19.529199] usb 3-2: SerialNumber: 000000000
[   23.185949] Bluetooth: hci1: Device setup in 3531095 usecs
[   23.185956] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[   25.308865] Bluetooth: hci1: Opcode 0x c03 failed: -110
[   27.442581] Bluetooth: hci1: Failed to read MSFT supported features (-110)
[   29.575753] Bluetooth: hci1: AOSP get vendor capabilities (-110)
[   29.710531] usb 3-2: reset high-speed USB device number 3 using xhci_hcd
[   29.832537] usb 3-2: device descriptor read/64, error -71
[   45.239019] usb 3-2: USB disconnect, device number 3
[   45.239430] mt7921u: probe of 3-2:1.3 failed with error -5
[   45.240098] usbcore: registered new interface driver mt7921u
[   52.492338] usb 3-2: new high-speed USB device number 4 using xhci_hcd
[   52.635829] usb 3-2: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[   52.635840] usb 3-2: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[   52.635844] usb 3-2: Product: Wireless_Device
[   52.635847] usb 3-2: Manufacturer: MediaTek Inc.
[   52.635850] usb 3-2: SerialNumber: 000000000
[   55.446130] Bluetooth: hci1: Device setup in 2721146 usecs
[   55.446140] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[   57.521725] Bluetooth: hci1: Opcode 0x c03 failed: -110
[   59.655143] Bluetooth: hci1: Failed to read MSFT supported features (-110)
[   61.788684] Bluetooth: hci1: AOSP get vendor capabilities (-110)
[   61.914667] usb 3-2: reset high-speed USB device number 4 using xhci_hcd

After the BT firmware has been removed:
$ sudo rm /usr/lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin.zst
everything looks fine:

[  259.956625] usb 3-2: new high-speed USB device number 6 using xhci_hcd
[  260.101393] usb 3-2: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[  260.101404] usb 3-2: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[  260.101408] usb 3-2: Product: Wireless_Device
[  260.101412] usb 3-2: Manufacturer: MediaTek Inc.
[  260.101415] usb 3-2: SerialNumber: 000000000
[  260.126503] bluetooth hci1: Direct firmware load for mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin failed with error -2
[  260.126516] Bluetooth: hci1: Failed to load firmware file (-2)
[  260.126525] Bluetooth: hci1: Failed to set up firmware (-2)
[  260.126530] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[  260.251556] usb 3-2: reset high-speed USB device number 6 using xhci_hcd
[  260.398357] bluetooth hci1: Direct firmware load for mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin failed with error -2
[  260.398368] Bluetooth: hci1: Failed to load firmware file (-2)
[  260.398375] Bluetooth: hci1: Failed to set up firmware (-2)
[  260.398380] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[  260.445886] mt7921u 3-2:1.3: HW/SW Version: 0x8a108a10, Build Time: 20240219110958a

[  260.708205] mt7921u 3-2:1.3: WM Firmware Version: ____010000, Build Time: 20240219111038
[  262.320588] mt7921u 3-2:1.3 wlp5s0f4u2i3: renamed from wlan0
[  366.545124] device wlp5s0f4u2i3 entered promiscuous mode
[  390.575563] device wlp5s0f4u2i3 left promiscuous mode

Frame injection and VIF is working:

$ sudo hcxdumptool -i wlp5s0f4u2i3 --rcascan=active
^C
788 Packet(s) captured by kernel
275 Packet(s) dropped by kernel
168 PROBERESPONSE(s) captured

$ sudo hcxdumptool -l
  3	  4	00c0cab574e6	980ee40b5d2f	*	wlp5s0f4u2i3    	mt7921u	NETLINK

Active monitor mode not:

$ sudo hcxdumptool -i wlp5s0f4u2i3 --rcascan=active -A
...
125 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: no PROBERESPONSES received (frame injection may not work as expected)
Possible reasons:
 no AP in range
 frames are filtered out by BPF
 driver is broken
 driver does not support frame injection

exit on sigterm

[ZerBea]

Now kernel 6.6.45.

As long as the BT stuff is removed,
VIF is working

$ hcxdumptool -l
  2	  5	00c0cab574e6	9c93e4b45d49	*	wlp5s0f3u3i3    	mt7921u	NETLINK

Monitor mode and packet injection is working:

$ sudo hcxdumptool -i wlp5s0f4u2i3 --rcascan=active

^C
2214 Packet(s) captured by kernel
208 Packet(s) dropped by kernel
651 PROBERESPONSE(s) captured

Active monitor mode is not working:

$ sudo hcxdumptool -i wlp5s0f4u2i3 --rcascan=active

^C
0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: too less packets received (monitor mode may not work as expected)
Possible reasons:
 no transmitter in range
 frames are filtered out by BPF
 driver is broken
Warning: no PROBERESPONSES received (frame injection may not work as expected)
Possible reasons:
 no AP in range
 frames are filtered out by BPF
 driver is broken
 driver does not support frame injection

My conclusion:
The ALFA AWUS036AXML has never worked if BT is installed.
Active monitor mode has never worked.
Since Linux kernel 6.11 the entire system crashes if the AXML has been plugged in.

[alexl83]

Thank you Mike! I'll see if I can get a kernel patched to remove active monitor for Oscar

Real deal would be for drivers to be fixed; do you think it is ever going to happen??

[ZerBea]

There is no need to patch the kernel, because monitor mode and frame injection is working as expected.
airgeddon is a script that use iw to set monitor mode:
https://github.com/v1s1t0r1sh3r3/airgeddon/blob/master/airgeddon.sh#L1518
It's enough to clear the flags here (flags none):
$ iw phy "${phy_interface}" interface add "${iface_monitor_et_deauth}" type monitor flags none 2> /dev/null

Real deal would be for drivers to be fixed; do you think it is ever going to happen??
Maybe if someone report this (BT & active monitor mode bug) to the linux wireless mailing list
Since I got this answer I do not report bugs any longer!
https://bugzilla.kernel.org/show_bug.cgi?id=219040#c11

[alexl83]

There is no need to patch the kernel, because monitor mode and frame injection is working as expected. airgeddon is a script that use iw to set monitor mode: https://github.com/v1s1t0r1sh3r3/airgeddon/blob/master/airgeddon.sh#L1518 It's enough to clear the flags here (flags none): $ iw phy "${phy_interface}" interface add "${iface_monitor_et_deauth}" type monitor flags none 2> /dev/null

Real deal would be for drivers to be fixed; do you think it is ever going to happen?? Maybe if someone report this (BT & active monitor mode bug) to the linux wireless mailing list Since I got this answer I do not report bugs any longer! https://bugzilla.kernel.org/show_bug.cgi?id=219040#c11

Thanks for the suggestion, thanks for your bug report | It is a very rude way to communicate with userbase, I feel sorry for them - hope @morrownr can get some noise on this topic

Thanks Mike, for your patience and support!
Ale

[ZerBea]

Rude is not the problem.
But from my point of view similar bugs should be collected under the same topic on bugzilla as described here (and not in mailing lists):
https://bugzilla.kernel.org/
"This bugzilla is for reporting bugs against upstream Linux kernels."
But this is obviously not the case:
https://bugzilla.kernel.org/show_bug.cgi?id=219040#c11

I think everyone can imagine what happens when one of this bugs reaches the major penetration testing distributions.

[alexl83]

Rude is not the problem. But my point of view similar bugs should be collected under the same topic on bugzilla as described here (and not in mailing lists): https://bugzilla.kernel.org/ "This bugzilla is for reporting bugs against upstream Linux kernels." But this is obviously not the case: https://bugzilla.kernel.org/show_bug.cgi?id=219040#c11

I think everyone can imagine what happens when one of this bugs reaches the major penetration testing distributions.

It's definitely not the case, not walking their talk - I guess developer who managed your report might not be driver's maintainer

I won't spend ~70€ for that adapter hoping to have it fixed one day, but I'm going to start raising kernel bugs on distribution trackers - hopefully they're considered a bit more - will start with debian
active monitor needs to be fixed for good

[ZerBea]

...but I'm going to start raising kernel bugs on distribution trackers
If you're running a distribution kernel that is exactly the recommended way:
"If you did not compile your own kernel from scratch, you are probably in the wrong place.
Please use the following links to report a bug to your distribution instead"
https://bugzilla.kernel.org/

Mostly I'm running three different versions (via systemd-boot):
a custom kernel == Linux mainline: 6.11-rc3
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/?h=v6.11-rc3
(compiled with Arch kernel config and - if needed - patched with Arch kernel patches)
https://gitlab.archlinux.org/archlinux/packaging/packages/linux
https://gitlab.archlinux.org/archlinux/packaging/packages/linux-lts

Arch Linux kernel == Linux stable: 6.10.5
https://archlinux.org/packages/core/x86_64/linux/

Arch Linux LTS kernel == Linux longterm: 6.6.46
https://archlinux.org/packages/core/x86_64/linux-lts/

If you run hcxlabtool or hcxdumptool you don't need to set active monitor mode.
Due to ASSOCIATION and REASSOCIATION attacks, you don't need to inject stupid DEAUTHENTICATION frames.
Both tools request PMKIDs from APs and EAPOL M2s from CLIENTs. JtR and hashcat can work on this hashes.

[alexl83]

FYI @ZerBea - if I clear monitor mode flags - my 7921e get unbearably slow in scanning - setting control + otherbss as flags alleviate decently (perhaps fcsfail too)

[ZerBea]

@alexl83
Good know that a workaround (for the AXML) has an impact on mt7921e devices.
Looks like every adapter needs different flags.
That's why hcxdumptool (without -A) leave the default flags untouched while -A set NL80211_ATTR_MNTR_FLAGS to NL80211_MNTR_FLAG_ACTIVE.

[morrownr]

@ZerBea @alexl83

Sorry for the delay. Health problems affecting my wife and I. I try to catch up when I can.

I just ran the following on my Edup adapter based on the mt7921au: (driver = mt7921u)

$ sudo hcxdumptool -i wlxe84e06aa849b --rcascan=active

^C
0 ERROR(s) during runtime
11713 Packet(s) captured by kernel
2635 Packet(s) dropped by kernel
2481 PROBERESPONSE(s) captured

exit on sigterm

I then ran the following on my Asus PCIe card based on the mt7922: (driver = mt7921e)

$ sudo hcxdumptool -i wlp2s0 --rcascan=active

^C
0 ERROR(s) during runtime
4147 Packet(s) captured by kernel
381 Packet(s) dropped by kernel
703 PROBERESPONSE(s) captured

exit on sigterm

I am not an expert with hcxdumptool so you will to tell me what I did and what it means. I can run additional tests. Certainly I would like to test active monitor but will test anything you want. Testing active monitor is a waste of time on any Realtek but I also have adapters based on mt7612u and mt7610u chips. I can also grab my axml to see what it does.

Mt opinion is that Alfa screwed something up in the axml.

I though Mediatek was the best wireless platform but it seems I got it wrong :(

I would argue that Mediatek is the best wireless platform for monitor mode and ap mode use cases. I've helped people with their wireless problems for several years. With usb adapters we only have the choice of Mediatel and Realtek. Mediatek is much better. I think Alfa just screwed this up with the axml because I am not seeing many of the reported problems with my Edup adapter with the same chip as the axml. There is no doubt there is a problem... exactly what the core issue is and how it can best be fixed is not obvious to me at this point but I am trying to see if we can get to the bottom of it and you guys are helping.

[ZerBea]

@morrownr
The scan mode is not an attack mode!
This command
$ sudo hcxdumptool -i wlp2s0 --rcascan=active
is similar to this command:
$ sudo iw dev wlp48s0f4u2u4 scan

The major difference:
hcxdumptool is doing a scan in monitor mode while iw is doing the scan in managed mode.
By default only the most common channels (1,6,11) are scanned.
Therefore hcxdumptool transmit an undirected PROBEREQUEST and counts the BEACONs and PROBERESPONSEs of APs in range.

On exit, you get some general information:
0 ERROR(s) during runtime -> ERRORs reported by raw socket (e.g. failed to transmit a frame, failed to receive a frame, failed to set channel)
4147 Packet(s) captured by kernel -> total received frames
381 Packet(s) dropped by kernel -> frames dropped by kernel https://unix.stackexchange.com/questions/144794/why-would-the-kernel-drop-packets
703 PROBERESPONSE(s) captured -> total PROBERESONSE frames received.

BTW:
I fully agree: The AXML is not a big deal!
Even on OpenWRT 23.05 (compiled via toolchain and running on a Raspberry Pi Zero) it stops working after awhile (on high work load - and hcxdumptool produce high work load when running in attack mode against APs and CLIENTs).

[ZerBea]

I forgot to mention:
As of today, I'm testing an ancient ALFA AWUS036NHA (longterm test since several weeks).
ZerBea/hcxdumptool#361 (comment)
It is working (Raspberry Pi Zero / OpenWRT 23.05 compiled via toolchain) a thousand times better (flawless!) than the AXML!

[morrownr]

@ZerBea

Thanks for the explanation on the test I did. Now, what command line should I use to test active monitor? I want to do a test on both my Edup adapter and the Alfa adapter to see if I see variances in results. I'll also test my mt7922 card as it uses the mt7921 driver as well.

[ZerBea]

@morrownr
first get information about the device:

$ hcxdumptool -L

Requesting physical interface capabilities. This may take some time.
Please be patient...

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  1   4 74da38f2038e 74da38f2038e * wlp48s0f4u2u4    mt7601u (NETLINK)

* active monitor mode available (reported by driver - do not trust it)
+ monitor mode available (reported by driver)
- no monitor mode available

If active monitor mode is available (as reported by the driver), run hcxdumptool in active monitor mode:
$ sudo hcxdumptool -i wlp48s0f4u2u4 --rcascan=active -A

If you see something like this, it is working:

^C
166 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
33 PROBERESPONSE(s) captured

exit on sigterm

If you see something like this (e.g. AXML) it is not working:

^C
0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: too less packets received (monitor mode may not work as expected)
Possible reasons:
 driver is broken (most likely)
 no transmitter in range
 frames are filtered out by BPF
Warning: no PROBERESPONSES received (frame injection may not work as expected)
Possible reasons:
 no AP in range
 frames are filtered out by BPF
 driver is broken
 driver does not support frame injection

exit on sigterm

If you see something like this please remove the BT firmware:

$ sudo dmesg
[40086.623224] usb 1-9.3: new high-speed USB device number 9 using xhci_hcd
[40086.754894] usb 1-9.3: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[40086.754902] usb 1-9.3: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[40086.754905] usb 1-9.3: Product: Wireless_Device
[40086.754907] usb 1-9.3: Manufacturer: MediaTek Inc.
[40086.754909] usb 1-9.3: SerialNumber: 000000000
[40086.869702] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20240716151445
[40089.987866] Bluetooth: hci0: Device setup in 3046908 usecs
[40089.987871] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[40092.149906] Bluetooth: hci0: Opcode 0x0c03 failed: -110
[40094.283289] Bluetooth: hci0: Failed to read MSFT supported features (-110)
[40096.416650] Bluetooth: hci0: AOSP get vendor capabilities (-110)
[40096.495174] usb 1-9.3: reset high-speed USB device number 9 using xhci_hcd
[40101.610086] usb 1-9.3: device descriptor read/64, error -110
[40107.500728] mt7921u: probe of 1-9.3:1.3 failed with error -5
[40107.501347] usb 1-9.3: USB disconnect, device number 9
[40108.563609] usb 1-9.3: new high-speed USB device number 10 using xhci_hcd
[40108.708754] usb 1-9.3: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[40108.708762] usb 1-9.3: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[40108.708764] usb 1-9.3: Product: Wireless_Device
[40108.708767] usb 1-9.3: Manufacturer: MediaTek Inc.
[40108.708768] usb 1-9.3: SerialNumber: 000000000
[40108.824807] Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20240716151445

At this point, it is possible that the entire USB subsystem became instable. So better to reboot your system.

I suggest to run Wireshark on a second interface/system to monitor the entire traffic.
This is the only way to see wether ACK frames are transmitted or not!

[morrownr]

Thanks. Now for some testing:

$ sudo hcxdumptool -L

Requesting physical interface capabilities. This may take some time.
Please be patient...

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   4 e8fb1c7e4dcb b025aaa83722 * wlp2s0           mt7921e (NETLINK)
 10  13 e84e06aa849b e84e06aa849b * wlxe84e06aa849b  mt7921u (NETLINK)

No luck:

^C
0 ERROR(s) during runtime
0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel

It was only scanning band 1. How do I get it to scan all bands? And should I test it in a USB2 port to see if there is an issue with that?

[ZerBea]

Add -F to scan all available (allowed by regulatory domain) frequencies.
Due to massive USB3 problems it might be good to test in on both (2 and 3).

[ZerBea]

BTW:
Are you running an older version of hcxdumptool?
Latest git head provide some more status information.

[morrownr]

Are you running an older version of hcxdumptool?

Not too old but now it updated.

I'll do some testing...

[morrownr]

Going to be a delay. Not feeling well but will continue when able.

[alexl83]

Going to be a delay. Not feeling well but will continue when able.

Take care, and guys - thanks a lot for your support and your efforts!

[kylefmohr]

@ZerBea Hi, I happen to have two mt7921u adapters (The EDUP AX3000M and the Panda PAU0F), I tried running those commands and didn't get any output like x Packet(s) captured by kernel. I recorded my terminal session if that helps at all

The two adapters are plugged into USB 3 ports, and are named wlan1 and wlan2 (I don't know which is which, but it shouldn't matter since they both do the same thing in this recording).

Let me know if there is more things I can do to help test this, I'd be happy to do so.

Thanks!

Edit: Did some additional testing. When an adapter is downgraded to using a USB 2.0 connection, scanning speeds in monitor mode are significantly improved. To be clear I just connected an adapter to a USB 2.0 extension cable and verified with lsusb.

Using a USB 3.0 extension cable (understandably) has no effect on scanning speeds, still very very slow.

[ZerBea]

@kylefmohr , thanks.
Monitor mode and packet injection is broken on several Linux Kernel versions. Looks like you are running one of these Linux Kernel versions.
As of today there is huge work in progress on mac80211. Most of the issues are related to this mac80211 stack, some on the drivers itself and some on both.
More information is here:
ZerBea/hcxdumptool#465
and here:
ZerBea/hcxdumptool#454
and here (broken packet injection on 5GHz):
morrownr/USB-WiFi#390 (comment)

You're running an old version of hcxdumptool. This version does not show possible reasons why packet injection is not working.
Latest version is here:
https://github.com/ZerBea/hcxdumptool

Due to the massive bugs (driver & mac80211) I decided to add more information to hcxdumptool,
e.g. how it was compiled:

$ hcxdumptool -v
hcxdumptool 6.3.4-41-g233b6e3 (C) 2024 ZeroBeat
running on Linux kernel 6.6.47-1-lts
running GNU libc version 2.40
compiled by gcc 14.2.1
compiled with Linux API headers 6.10.0
compiled with GNU libc headers 2.40
enabled REALTIME DISPLAY
enabled GPS support
enabled BPF compiler

e.g. errors occurred during runtime:

$ sudo hcxdumptool --rcascan=active
^C
0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
Warning: too less packets received (monitor mode may not work as expected)
Possible reasons:
 driver is broken (most likely)
 no transmitter in range
 frames are filtered out by BPF
Warning: no PROBERESPONSES received (frame injection may not work as expected)
Possible reasons:
 no AP in range
 frames are filtered out by BPF
 driver is broken
 driver does not support frame injection

exit on sigterm

while it is not broken if the device was plugged in an USB2 port:

$ sudo hcxdumptool --rcascan=active
^C
35 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
19 PROBERESPONSE(s) captured

exit on sigterm

As well as an expanded debug log - which can we activated in Makefile:

# uncomment to enable DEBUG log
#DEFS		+= -DHCXDEBUG

As you can see, running this kernel:

$ uname -r
6.6.47-1-lts

Monitor mode and frame injection is completely broken if my mt76 device was plugged in an USB3 port!

Additional on kernel 6.11-rc 1-4, my entire system crashes if I plug in an ALFA AWUS036AXML:
https://bugzilla.kernel.org/show_bug.cgi?id=219040#c9

I closed this issue report here, because there are much bigger problems than a "not working active monitor mode".
When all these problems have been fixed, than we can talk about active monitor mode again.

BTW:
Bisecting the bugs mentioned above us useless, because there is more than one problem, e.g. BT:
https://bugzilla.kernel.org/show_bug.cgi?id=219040
That never worked.

OpenWRT 23.05 isn't flawless too. It crashes after a while running an ALFA AWUS036AXML under heavy traffic.
It is compiled via toolchain which means the entire BT stuff was not compiled!

[kylefmohr]

@ZerBea

Thanks! I hadn't seen those, it looks like some good progress is being made.

Apologies if I made it sound like the fault was with hcxtools, my intention is to help figure out what's wrong with MediaTek's driver for this chipset. I'll let this thread die finally, and continue to keep an eye on morrownr/USB-WiFi#107 which is open for tracking bugs with this driver (as well as the other threads you linked).

I have used various hcxtools for years and years now and they have never steered me wrong. Thanks for all of your hard work, it is appreciated.

[ZerBea]

I forgot to mention that the only distribution that works with most of my devices is OpenWRT 23.05!
I'm sure, if it moves to kernel 6.6 more devices will work due to better driver support:
rtw88 (instead of rtl8812au) https://github.com/lwfinger/rtw88 (USB device support)
rtlwifi (instead of rtl8192cu)
latest rtl8xxxu

[ZerBea]

@kylefmohr , you're welcome.

Don't worry about that, I've bisected the Linux kernel and I know that none of this problems is caused by hcxdumptool.
As of today it is hard to identify the problems. Too many screws were turned (mac80211 and drivers) at the same time.
Last time it was the mac80211 stack that caused the broken monitor mode.

[morrownr]

Hi @kylefmohr

The EDUP AX3000M and the Panda PAU0F

I could use a report on the Panda PAU0F. I have the EDUP adapter and think it is excellent but not much info on the Panda adapter yet. I want the info for my Plug and Play List.

Too many screws were turned (mac80211 and drivers) at the same time.

I agree with this assessment. USB WiFi adapters, particularly the newer models, have been taking a hit on Linux over the last several months because they depend on 3 subsystems or stacks if you will. They depend on the following stacks: wireless, bluetooth and usb.

The wireless stack has been undergoing a lot of modernization work to support WiFi 6 and 7 features and it is playing hell on many existing drivers. The USB stack, particularly the usb 3 support, is problematic also but USB3 was never one of mankind's greatest inventions. As we can see with some of the mt7921au based adapters on some systems, even bluetooth can shut wifi down. It is not a good time to be on the bleeding edge and most of my advice to users is to back off to kernel 6.6 or 6.1 if it is a system you need to work without wifi bugs right now.

[kylefmohr]

@morrownr replied back in morrownr/USB-WiFi#107 let me know if you'd like any more info!

[OscarAkaElvis]

Does anybody have any news about this? It's a pity that the mediatek chipset, one of the best, is not working correctly on newer kernel versions 😢

I was checking the kernel bug tracker:

https://bugzilla.kernel.org/show_bug.cgi?id=219040 <- this was a failure with a sad ending

https://bugzilla.kernel.org/show_bug.cgi?id=218763 <- this I opened myself was mostly avoided asking me to do something that I don't have time (and probably also the skills) to do

by the way... @ZerBea , I need to contact you to ask you something offtopic of this, but I can't find an email, a twitter account, discord or something (you hardened your presence on social media! haha... anyway I'm not an OSINT expert). If you have time, please contact me (my email is public on my profile, or on airgeddon discord server or wherever).

[ZerBea]

You should have received an email now.