ALFA AWUS036AXM. Problems with frame injection in monitor mode. (chipset = mt7921au, driver = mt7921u)

[anhersol]

Hi! We have an ALFA AWUS036AXM. We need to work in monitor mode for investigation purposes. However, injection is not possible in a first time. After some changes (but without any reproducible criterion) down/up managed/monitor, the injection starts. However, it is carried out erroneously with 1/6Mbps (2,4GHz) and 6Mbps (5GHz). In the file attached, we include information about the context, tests and detected problem. tarjeta ax_attach.pdf

We would be very grateful if you could provide us any help in order to resolve the issue or alternatively someone to contact. Many thanks in advance, Best regard,

Ángela Hernández

[morrownr]

Hi @anhersol

I am bringing @ZerBea into the conversation, if he has time, as he is an expert in this area. @deren might be interested as well or know who would be interested as this issue is really causing problems with those wanting to use active monitor mode. The problem is not there with the mt7612u and mt7610u drivers.

https://github.com/openwrt/mt76/issues/839

Some recommendations for you to try:

The mt7921u driver currently has a bug in active monitor mode so you might want to try without active.

ifconfig is depreciated. Try:

iw dev sudo ip link set down sudo iw set monitor none (you can change none to what you like, just not active for now) sudo ip link set up iw dev

@morrownr

[anhersol]

Hi @morrownr!

Thank you for your quick answer. We have tried your recommendation but the problem is the same without active monitor. Many thanks for bringing us with @ZerBea into the conversation. Also for @deren contact. Our problems are the same.

Concerning AWUS036ACM (mt7612u), monitor mode works. It injects frames correctly but, it has other problems. For instance, control of number of retries, rts-cts off, don't work properly.

Regards, Ángela

[ZerBea]

Hi @anhersol

As of today (unfortunately) none of the drivers (of kernel 6.7) is really flawless and there are a lot of setscrews attention should be given to, e.g:

firmware
kernel version and driver
operating system
programming language of application

I'm running two environment systems:

Arch Linux (custom configured - tailored to code hcxdumptool/hcxlabtool)
OpenWRT (custom configured - tailored to test hcxdumptool/hcxlabtool)

Preferred programming language is ASM and C. I avoid to use additional libraries like libnl or third party tools like scapy. It is hard enough to understand the kernel itself and I don't like to waste my time to figure out what's going on inside this third party tools (e.g. runtime within the library function). Please take a look at this comment (RUST vs C) which should explain what I mean; https://github.com/ZerBea/hcxdumptool/issues/414#issuecomment-1948078429

That limits my adjusting screws enormously - how about your screws (scapy PF_PACKET socket)?

[ZerBea]

If you have everything under control, the next step is to monitor the RF channel, because what tcpdump shows you does not correspond to reality on the RF channel: https://www.networkcomputing.com/wireless-infrastructure/wifi-spectrum-analysis-uncovering-rf-interference

The final step is (if needed) to modify the firmware and/or to modify the driver and/or to modify your application.

[morrownr]

The final step is (if needed) to modify the firmware and/or to modify the driver...

Let's me add the link to the Mediatek Linux Wireless site as I think we really need the right people connected to the right Mediatek devs so there can be direct communication about the needs and the problems that are being observed with monitor mode use cases.

https://wireless.wiki.kernel.org/en/users/drivers/mediatek

Note the listed email address at the bottom of the page. I'm not saying to use them yet. Let me see if we can get started with the below paragraph.

@deren, sir, what I have been noticing is that there are issue with monitor mode in the mt7610u, mt7612u, and mt7921u drivers and this is something where more normal bug reporting may not work well. Can I propose that establishing contact between knowledgeable users and the correct Mediatek devs to work a series of monitor modes issues seems to be the best solution. If you could help make this happen, it would be greatly appreciated.

@morrownr

[ZerBea]

Hi @morrownr That sounds good.

BTW: We can add mt7601u to the list, too https://bugzilla.kernel.org/show_bug.cgi?id=217465

BTW2 (out of scope): TP-Link TL-WN8200ND(un) v3 (driver rtl8xxxu / rtl8192) found its way into the kernel. Unfortunately it does not transmit: https://bugzilla.kernel.org/show_bug.cgi?id=218528

And the problem on rtl8xxxu / rtl8188 still exists: https://bugzilla.kernel.org/show_bug.cgi?id=217205#c83

But anyway (as of today and kernel 6.8-rc6) my rtl8xxxu devices beat the mt76 devices (running hcxlabtool). The hardware (mt76 chipsets) is fine, but driver and firmware need to be fixed. The same applies to the rtl8xxxu devices. The driver still need to be patched (to work as expected).

[anhersol]

Hi all!

@ ZerBea. Thank you for your suggestions. We also have a more complete C program and we still have the same problem regarding the active monitor mode with a AWUS036ACM card. Problems refer to the control of retries, rts-cts, etc. We will test with this C program the AWUS036AXM card to see if the injection problems persist. We don't think that the problem was python although we agree that it has large limitations compared to C. We only use this simple code to do easy and fast tests. Really, we have seen the AWUS036AXM inject but erroneously (6Mbps instead of required MCSs). We receive in the RF channel.

@morrorw , many thanks to contact for all of us with @deren. It is great new. Let's see if together we can get the monitor mode to work. Thanks!!

Regards, Ángela

[ZerBea]

Thanks for the explanation. I can confirm this behavior of the device. Luckily hcxdumptool/hcxlabtool benefits from that. Doing an AUTHENTICATION / ASSOCIATION using the lowest possible rate and the smallest bandwidth makes sure that we get a PMKID from the AP and/or an EAPOL handshake M1M2M3 and/or an EAPOL M2 from the CLIENT as response on our request.

BTW: Please also check the targets time response behavior. I have several "nervous" CLIENTs (test target devices). If the attack device doesn't respond within their timeout gap, they flood the channel with retries.

[anhersol]

Hello @ZerBea.

In one of our tests, we injected frames to a non-existent MAC. The problem with retries is that the number is always 15 regardless of the retry limit defined (7 or another limit).

[ZerBea]

Looks like either we can disable it (I'm doing this to avoid to spam the channel) or we have to accept the default value (as stored in the firmware). The radiotap injection header of hcxlabtool:

static const u8 rthtxdata[] =
{
0x00, 0x00, /* radiotap version and padding */
0x0c, 0x00, /* radiotap header length */
0x06, 0x80, 0x00, 0x00, /* bitmap */
0x00, /* all flags cleared */
0x02, /* rate */
0x18, 0x00 /* tx flags */
};
#define RTHTX_SIZE sizeof(rthtxdata)

It is also possible to set the rate via NETLINK (NL80211). Unfortunately both variants (radiotap and NETLINK) sometimes are ignored by the device (which might be related to the firmware, too).

[Dxploto]

Hi everyone, I encountered a similar problem. @anhersol, it seems that the MT7921u ignores all injected frames when the wrong Radiotap is set up. And sometimes, when you set non-critical error parameters in radiotap, the rate will be set at the default value as you have seen. For me, the new problem is that the MT7921u cannot inject VHT frames. My test platform is ubuntu 22.04 kernel version 6.5. I made some attempts, including updating the firmware to the version of 20240219 and modifying Radiotap parameters, but these attempts failed. However, under the same platform and using the same set of Radiotap parameters, MT7612 can correctly inject VHT frames. Is it possible to solve these problems? Mediatek‘s wireless cards currently have the best support for the injection function since other cards are even worse. Also, thank you very much for your contributions to the mantance of usb wifi card driver. @morrownr