morrownr
ALFA AWUS036AXM. Problems with frame injection in monitor mode. (chipset = mt7921au, driver = mt7921u)
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
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
@morrownr
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
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)?
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.
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
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).
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
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.
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).
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).
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
Hi! Returning to @anhersol's initial comment, we have performed new injection tests in monitor mode with the ALFA AWUS036AXML card. For this we have used the new firmware of September this year of the MT7921u driver. The card seems stable and the active monitor mode works correctly on the ALFA AWUS036AXML card. The curious thing is that the active monitor mode, in addition to the ACKs of incoming unicast packets, must also be configured to avoid transmission retries despite receiving the corresponding ACKs of injected unicast packets. However, whatever the chosen WiFi version (802.11a, 802.11n, 802.11ac, 802.11ac), the injection, although possible, is performed incorrectly at rates of 1/6Mbps (2.4GHz) and 6Mbps (5GHz). In the attached file we include information about the context, tests and detected problems.
We would be very grateful if you could provide us with any help in resolving the issue or alternatively someone to contact. Many thanks in advance.
Best regards,
Pepe
@jose-ruiz-mas
Pepe,
See: https://wireless.docs.kernel.org/en/latest/en/users/drivers/mediatek.html
Note the emails addresses and mailing lists near the end of the page. Both of the linux-wireless@ mailing lists require text only messages, not html. I think you have to be subscribed to the mailing lists as well for messages to go through.
Remember, these are kernel developers, they are busy. Make your report professional by providing concise details about the kernel version, firmware version adapter chipset. Then provide details on how to duplicate the problem as well as a description of what you expect the behavior to be.
If you need help with any of the above, let me know.
@morrownr
Hi @morrownr!
Thank you for your quick response. We will try to contact them to let them know the problems we have encountered.
Regards,
Pepe
Hi @jose-ruiz-mas ! I encountered the same issue. My MT7921au can't inject VHT/HT packets，but MT7612 is working fine. Was your previous problem resolved?
Hi @skyrainbowbridge!
Unfortunately, the problem continues. The latest firmware (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek) dated 2024-11-12 does not fix the problem either. In addition, I have tried to contact Deren Wu [email protected], author of the firmware, but there has been no response. It is quite possible that I have not used the correct way to do so.
If we find a solution, we would share it in this issue. Likewise , we would be very grateful if we could be provided with any help in resolving the problem or alternatively someone to contact. Many thanks in advance.
Best regards,
Pepe
I think posting to linux-wireless is more useful than trying to contact a dev directly. I doubt he reads that email.
@jose-ruiz-mas
@bjlockie gives good advice.
I can give you some pointers on subscribing to linux-wireless. Keep in mind that this list is the MAIN communications list for Linux Wireless kernel devs so it would be best to monitor for a while before posting. That way you may understand how best to make a message that will be answered. One thing is for certain though and that is that you have to post a way that can help devs duplicate the problem.
Also, if it is a Mediatek related issue, then addressing (CCing) the public Mediatek devs on the same message would be a good idea. You can find a list here:
https://wireless.docs.kernel.org/en/latest/en/users/drivers/mediatek.html
Once you have the checklist of what to do to duplicate the problem, post it here so maybe I and others can take a look and try to duplicate the problem.
Hi @morrownr, @bjlockie
Many thanks for your advice. We will try to do what you suggest.
Below you can find all the information to reproduce the problem. I hope it's enough.
Many thanks in advance.
Regards,
Pepe
We have performed injection tests in monitor mode with the ALFA AWUS036AXML card. For this we have used the firmware of August 2024 of the MT7921u driver. The card seems stable and the active monitor mode works correctly on the ALFA AWUS036AXML card. The curious thing is that the active monitor mode, in addition to the ACKs of incoming unicast packets, must also be configured to avoid transmission retries despite receiving the corresponding ACKs of injected unicast packets. The ALFA AWUS036AXML card injects, at 2.4GHz and 5GHz (sometimes it fails in this band, without knowing why), but the injection performed is incorrect. Whatever the WiFi version chosen (802.11a, 802.11n, 802.11ac, 802.11ax), the injection, although possible, is carried out incorrectly and always at speeds of 1Mbps (2.4GHz) and 6Mbps (5GHz), never to the rate or MCS selected.
Below we include information about the context, tests and detected problems.
Computer:
Intel_client_Systems NUC13 ANKi5 Model name: 13th Gen Intel Core i5-1340P x16
lsb_release -a
No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.5 LTS Release: 22.04 Codename: jammy
uname –a
Linux NUC8 5.19.9 #2 SMP PREEMPT_DYNAMIC Tue Feb 20 18:06:38 CET 2024 x86_64 x86_64 x86_64 GNU/Linux
The installed driver is mt7921u (firmware of August 2024) and the kernel we have test are linux-5 .19. 9, linux-6 . 0.1 and linux-6 . 5.0-17:
modinfo mt7921u
filename: /lib/modules/5.19.9/kernel/drivers/net/wireless/mediatek/mt76/mt7921/mt7921u.ko license: Dual BSD/GPL author: Lorenzo Bianconi [email protected] firmware: mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin firmware: mediatek/WIFI_RAM_CODE_MT7961_1.bin srcversion: DE175EEC0CC6A3BFEC48B56 alias: usb:v0E8Dp7961ddcdscdpicFFiscFFipFFin* depends: mt76-connac-lib,mt76-usb,mt7921-common,mt76 retpoline: Y intree: Y name: mt7921u vermagic: 5.19.9 SMP preempt mod_unload modversions sig_id: PKCS#7 signer: Build time autogenerated kernel key sig_key: 35:EE:CB:A0:30:F7:33:44:93:83:53:4C:62:26:D8:F1:FA:80:9E:4A sig_hashalgo: sha512 signature: 10:F8:74:C4:0F:C4:EC:FF:D4:11:D8:40:E7:88:F0:53:E4:1E:63:AD: 69:A5:9D:19:06:30:8D:62:FB:FD:F0:83:E9:4A:B5:9C:08:18:A6:4D: FE:62:00:EC:3B:4A:96:AE:7B:6A:1E:2E:6A:A2:1E:B7:C5:E5:02:03: C4:29:7A:5A:40:16:97:81:F2:69:39:44:C8:8F:97:BE:A6:4F:8B:04: 8C:21:2C:81:64:A5:03:7F:D5:5A:D3:2F:BC:C1:CC:AA:61:08:A2:F7: F5:03:53:9C:59:63:7B:86:61:6C:1C:B2:08:8C:B6:88:F5:F1:90:30: EC:75:27:9B:CE:11:D4:B3:8A:9E:E6:67:78:72:DA:3C:F5:51:22:1F: 11:69:F4:A9:09:86:7E:A5:BA:48:D2:42:90:ED:A9:DB:C9:33:3B:DC: CE:73:8F:9E:04:4A:63:24:0C:80:83:A7:BA:9B:98:40:97:31:FF:0D: 6F:E8:A9:21:68:38:66:91:10:33:C1:27:2A:E7:64:6A:DB:08:4F:A4: 3A:CD:1E:80:1E:37:59:1D:1A:B7:4A:4F:1B:1C:9B:55:76:0F:BF:39: 63:5D:4F:11:C6:F6:20:7C:83:5D:C7:D1:BE:AE:B2:9D:CF:25:43:BC: C8:42:0B:A5:0F:68:A8:C5:D4:3B:43:3D:CE:B8:E1:C7:69:0C:E9:88: 07:4C:FF:CA:0F:D8:7A:31:17:7F:20:33:B9:09:EF:48:A3:8F:A2:A2: BF:BC:73:8E:9B:01:5F:01:76:13:38:DF:A9:9B:51:47:96:59:DD:07: 6C:61:56:A6:FD:1C:92:9B:51:2D:92:6E:FF:84:2E:6B:7F:08:EB:19: AD:6F:94:4E:25:6C:45:73:BD:2F:D1:64:60:46:51:D6:F5:4A:8F:19: 4A:57:79:D7:7A:12:38:A1:8E:23:76:24:AB:36:DB:BF:95:40:9C:CE: 2E:21:3F:4B:7A:AE:16:3F:77:ED:02:6F:82:00:76:6D:5D:25:2B:8F: 6E:F1:97:CA:12:75:31:AD:39:FB:90:45:5D:40:41:FD:F6:64:BD:12: ……………………………………
ethtool -i wlx00c0cab574d0
driver: mt7921u version: 5.19.9 firmware-version: ____010000-20240826151030 expansion-rom-version: bus-info: 3-2:1.3 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
We configure monitor mode as root:
ip link set wlx00c0cab574d0 down iw reg set ES iw dev wlx00c0cab574d0 set type monitor iw dev wlx00c0cab574d0 set monitor active ip link set wlx00c0cab574d0 up iw dev wlx00c0cab574d0 set channel 161 HT40+
iw dev wlx00c0cab574d0 info
Interface wlx00c0cab574d0 ifindex 8 wdev 0x100000001 addr 00:c0:ca:b5:74:d0 type monitor wiphy 1 channel 161 (5805 MHz), width: 20 MHz (no HT), center1: 5805 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 0 0
ifconfig wlx00c0cab574d0
wlx00c0cab574d0: flags=4163<UP, BROADCAST, RUNNING, MULTICAST> mtu 1500 unspec 00-C0-CA-B5-74-D0-9E-D0-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 16298194 bytes 7435039640 (7.4 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ip link show
wlx00c0cab574d0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ieee802.11/radiotap 00:c0:ca:b5:74:d0 brd ff:ff:ff:ff:ff:ff
Tests
In order to test easily the injection we have a simple code with Python3 (we also have a more complete C program and we have the same problem). See the example with 802.11n (testing has also been performed on 802.11a, 802.11ac and 802.11ax). We sent sequentially with all the MCS, from 0 to 15. We have already used it with other ALFA AWUS036ACH card (wlx00c0cab2a91a) and the injection is ok.
ethtool -i wlx00c0cab2a91a
driver: rtl8812au version: v5.13.6-15-gc40b977e2.20210629 firmware-version: 52.14 expansion-rom-version: bus-info: 3-3:1.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no
Simple code with Python3:
#------------------------------------------------------------------------------------------------------------------------------- import datetime import time import sys from scapy.layers.dot11 import * from scapy.layers.dot11 import Dot11, LLC, RadioTap, Dot11Beacon, Dot11Elt, Dot11ProbeResp from scapy.layers.inet import UDP from scapy.packet import Raw from scapy.utils import hexdump, checksum AP_MAC_T = '00:c0:ca:b5:74:d0' AP_MAC_R = '00:c0:ca:b2:a9:1a'
IFACE_T="wlx00c0cab574d0" #IFACE_T="wlx00c0cab2a91a"
mcs=[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15] packet = [] pkt= [] qoscontrol = b'\x80\x00' ip = bytes('\xaa\xaa\x03\x00\x00\x00\x08\x00' '\x45\x00\x00\x1c\x00\x00\x00\x00' '\x80\x11\xa4\xf7\xc0\xa8\x02\x01' '\xc0\xa8\x89\xc9', encoding = "latin-1") udp = bytes('\x00\x1a\x00\x1e\x00\x08\x12\x34', encoding = "latin-1")
#guard_interval(long GI '0', short GI '1') y MCS_bandwidth(20 MHz '0', 40 MHz '1',20MHz L '2', 20MHz U '3',) y HT_format (mixed '0', greenfield '1') #MCS_index (0 a 15)
for i in range(16): pkt1=(RadioTap(present="MCS",KnownMCS="MCS_index+MCS_bandwidth+guard_interval+HT_format",HT_format=0, MCS_index=int(i),MCS_bandwidth=0,guard_interval=0) / Dot11(type=2, subtype=0, addr1=AP_MAC_R, addr2=AP_MAC_T,addr3=AP_MAC_T) / ip / udp ) sendp(pkt1, iface=IFACE_T, verbose=False) #-------------------------------------------------------------------------------------------------------------------------------
Captures with tcpdump:
Test 1 ¬¬¬¬------- AP_MAC_T = '00:c0:ca:b2:a9:1a' AP_MAC_R = '00:c0:ca:b5:74:d0' IFACE_T="wlx00c0cab2a91a"
18:06:30.654721 216597130us tsft 5805 MHz 11n -12dBm signal 6.5 Mb/s MCS 0 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:30.702309 216644825us tsft 5805 MHz 11n -12dBm signal 13.0 Mb/s MCS 1 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:30.750264 216692702us tsft 5805 MHz 11n -12dBm signal 19.5 Mb/s MCS 2 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:30.809385 216748922us tsft 5805 MHz 11n -12dBm signal 26.0 Mb/s MCS 3 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:30.841334 216783889us tsft 5805 MHz 11n -12dBm signal 39.0 Mb/s MCS 4 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:30.880951 216823497us tsft 5805 MHz 11n -12dBm signal 52.0 Mb/s MCS 5 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:30.934368 216876826us tsft 5805 MHz 11n -12dBm signal 58.5 Mb/s MCS 6 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:30.974249 216916761us tsft 5805 MHz 11n -12dBm signal 65.0 Mb/s MCS 7 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:31.018121 216960628us tsft 5805 MHz 11n -10dBm signal 13.0 Mb/s MCS 8 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:31.053101 216995566us tsft 5805 MHz 11n -10dBm signal 26.0 Mb/s MCS 9 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:31.126546 217069040us tsft 5805 MHz 11n -10dBm signal 39.0 Mb/s MCS 10 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:31.174162 217116641us tsft 5805 MHz 11n -11dBm signal 52.0 Mb/s MCS 11 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:31.217853 217160360us tsft 5805 MHz 11n -10dBm signal 78.0 Mb/s MCS 12 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:31.257086 217199547us tsft 5805 MHz 11n -10dBm signal 104.0 Mb/s MCS 13 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:06:31.301771 217244264us tsft 5805 MHz 11n -11dBm signal 117.0 Mb/s MCS 14 20 MHz long GI [bit 22] IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0
AWUS036ACH injection is fine (wlx00c0cab2a91a) AWUS036AXML reception is fine (wlx00c0cab574d0)
Test 2 ¬¬¬¬------- AP_MAC_T = '00:c0:ca:b5:74:d0' AP_MAC_R = '00:c0:ca:b2:a9:1a' IFACE_T="wlx00c0cab574d0"
18:11:27.477373 6.0 Mb/s 5805 MHz 11a -14dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.524973 6.0 Mb/s 5805 MHz 11a -16dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.580369 6.0 Mb/s 5805 MHz 11a -15dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.629097 6.0 Mb/s 5805 MHz 11a -14dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.681501 6.0 Mb/s 5805 MHz 11a -15dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.719842 6.0 Mb/s 5805 MHz 11a -16dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.770228 6.0 Mb/s 5805 MHz 11a -15dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.817033 6.0 Mb/s 5805 MHz 11a -16dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.881225 6.0 Mb/s 5805 MHz 11a -18dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.924399 6.0 Mb/s 5805 MHz 11a -16dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:27.964050 6.0 Mb/s 5805 MHz 11a -14dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:28.011900 6.0 Mb/s 5805 MHz 11a -19dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:28.054279 6.0 Mb/s 5805 MHz 11a -15dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:28.108994 6.0 Mb/s 5805 MHz 11a -17dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:28.165202 6.0 Mb/s 5805 MHz 11a -13dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0 18:11:28.212790 6.0 Mb/s 5805 MHz 11a -15dBm signal IP 192.168.2.1.26 > 192.168.137.201.30: UDP, length 0
AWUS036AXML injection failed (wlx00c0cab574d0). Tx is performed at a rate of 6Mb/s instead of the selected MCS
The ALFA AWUS036AXML card injects, at 2.4GHz and 5GHz, but the injection performed is incorrect. Transmission is performed at a rate of 1Mb/s or 6Mb/s instead of the selected rate or MCS. The same goes for the rest of the WiFi versions.
@jose-ruiz-mas
You are on your way to a solid report that could go into linux-wireless. However, let me suggest some changes.
The installed driver is mt7921u (firmware of August 2024) and the kernel we have test are linux-5 .19. 9, linux-6 . 0.1 and linux-6 . 5.0-17:
Reporting a problem without trying the very latest won't go over well as the devs are regularly patching issues and they don't like to address issues that very well could already be fixed so the reporter needs to test the latest. The latest WiFi firmware for your device is from November of 2024 and the latest kernel is 6.13 rc6.
ifconfig wlx00c0cab574d0
ifconfig is depreciated. Please use iw and ip depending on what you want.
driver: rtl8812au version: v5.13.6-15-gc40b977e2.20210629
That appears to be from a Realtek out-of-kernel driver. You should use an in-kernel driver for examples. The new rtl8812au driver was merged in kernel 6.13.
Hope this helps.