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.