Active monitor mode is broken on several mt76 drivers (since a long time)

[deep4lpha]

Hi,

I'm running kernel 6.18.12 with stock mt76/mt76x0u driver and I'm strugging to run hcxdumptool in active mode.

I switch the interface to monitor mode:

iw dev alfa1 set type monitor

My lab AP is broadcasting on 5Ghz channel 48, so I run hcxdumptool like this:

hcxdumptool -i alfa1 -w dump.pcapng -c 48b --rds=3 -A

Tool starts fine, but I can see the table showing nearby APs on channel 1b ONLY. Needless to say, it does not attack my lab AP. When I exit hcxdumptool it leaves the driver in broken state, since I can't switch to any other channel until I unload and load mt76x0u again.

When hxc leaves driver in broken state airodump-ng reports:

 CH 48 ][ Elapsed: 0 s ][ 2026-02-19 10:32 ][ fixed channel alfa1: -1

I tried forcing channel with iw dev alfa1 set channel but only mod reload helps.

Please tell me it's me doing something wrong. I fucking hate running hcx via VMs or OpenWRT and would love to run in on modern kernel without fucking around with shitty hardware and cable mess.

EDIT: and yes, I renamed the interface with udev from bullshit name to friendly name, hence alfa1 not wlpmacaddressfuckyou ;)
EDIT2: other tools work fine - I can deauth and capture handshakes with aircrack or bettercap. They are fine - I can crack those handshakes despite hcxpcapngtool being a princess it is refusing to convert them to hashcat forma.

[ZerBea]

This issue is easy to fix: Remove the -A option from your command line and everything is fine!

$ hcxdumptool -i alfa1 -w dump.pcapng -c 48b --rds=3

Active monitor mode (-A) is broken on all mt76 drivers since a long time!

[deep4lpha]

Oh man, you saved the day! Of course it works flawlessly without -A flag! And I don't need to touch realtek drivers with a stick. Thanks!

[ZerBea]

BTW:
It is not hcxdumptool that crashes the driver.
If you try to set active monitor mode by iw this also happens.

An example:

$ sudo hcxdumptool -c 48b --rcascan=active^C
^c
109 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
101 BEACON(s) received
2 PROBEREQUEST(s) transmitted
8 PROBERESPONSE(s) received
1 ACCESS POINT(s) discovered
1 ACCESS POINT(s) responded
exit on sigterm

Now, use iw with active monitor mode flag to crash the driver:

$ sudo ip link set wlp48s0f4u2u3 down
$ sudo iw dev wlp48s0f4u2u3 set monitor active
$ sudo ip link set wlp48s0f4u2u3 up
$ sudo iw dev wlp48s0f4u2u3 set channel 48
$ sudo hcxdumptool -c 48b --rcascan=active
^C
258 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
216 BEACON(s) received
0 PROBERESPONSE(s) received (packet injection probably won't work)
2 undirected PROBEREQUEST(s) received
3 ACCESS POINT(s) discovered
exit on sigterm

BTW:

EDIT2: other tools work fine - I can deauth and capture handshakes with aircrack or bettercap
You cant compare hcxdumptool (running in active monitor mode) with airodump-ng or bettercap (running in normal monitor mode).
I'm absolutely sure that when you doing this commands (set active monitor mode) before you start airodump-ng or bettercap, both tools will fail epically and the driver is crashed!

$ sudo ip link set wlp48s0f4u2u3 down
$ sudo iw dev wlp48s0f4u2u3 set monitor active
$ sudo ip link set wlp48s0f4u2u3 up
$ airodump-ng or bettercap

This issue has been reported 2023 to upstream and it is still unfixed:
openwrt/mt76#839

I'll change the head line, because it is a driver issue!

[deep4lpha]

Yeah the drivers are a major issue right not. Recent cleanup in kernel 6.17 broke out-of-kernel drivers for Realtek and rds88 suck even more. However you gotta admit - the cleanup improved stability. Tried this on 6.18.xx and 6.12.xx. On 6.18 the module is broken, but reload brings it back. On 6.12 kernel dumps a traceback with null pointer dereference in mt76 and system becomes unusable (sudo not working, reboot hangs etc).

[ZerBea]

BTW:
hcxdumptool is not(!) a princess - it's the Evil Queen of the Night. :)

[deep4lpha]

Haha, as frustrating as it is to manually debug how to convert stuff to hashcat format I completely understand underlying premise. Rational decision to focus on reliability of captured cryptographic material. So she's a sassy queen then 😆

[ZerBea]

For other readers of this discussion:

It's completely useless to report driver bugs here!
I'm not a developer of drivers!
Developers of drivers don't read this here!
The driver will never ever be fixed if you don't report it either to upstream or to bugzilla!