[Help]: MT7925 monitor mode not working (maybe)

[dbie0]

Checklist

• I acknowledge that support is provided on a best-effort basis.
• I acknowledge that the authors and contributors to this repository cannot be held responsible for the results of my use of any information contained in or linked from this repository.

uname

Linux kali 6.11.2-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.11.2-1kali1 (2024-10-15) x86_64 GNU/Linux

lsusb

(lspci -v) 00:10.0 Network controller: MEDIATEK Corp. Device 7925 Subsystem: AzureWave Device 6002 Physical Slot: 16 Flags: bus master, fast devsel, latency 0, IRQ 35 Memory at fe200000 (64-bit, non-prefetchable) [size=2M] Memory at fea50000 (64-bit, non-prefetchable) [size=32K] Capabilities: [80] Express Endpoint, IntMsgNum 0 Capabilities: [e0] MSI: Enable+ Count=1/32 Maskable+ 64bit+ Capabilities: [f8] Power Management version 3 Kernel driver in use: mt7925e Kernel modules: mt7925e

rfkill

0: phy0: Wireless LAN Soft blocked: no Hard blocked: no

dkms

sudo: dkms: command not found

iw

phy#0
	Interface wlan0
		ifindex 3
		wdev 0x1
		addr c0:bf:be:05:ec:c2
		type monitor
		channel 7 (2442 MHz), width: 20 MHz (no HT), center1: 2442 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

What happened?

Hi folks, I'm trying to use MT7925, M.2 version, in monitor mode, unfortunately it doesn't work. There is no output from airmon-ng but there are messages in dmesg.

Exact steps to reproduce I described in my GitLab: https://gitlab.com/db314/mt7925
Summary, additional details and experiments:

• I'm using latest Kali rolling
• Host is Dell WYSE 5070
• I tried with latest firmware (20241104133053) from kernel.org and FW that comes with Kali
• I tried the same steps with Intel 9650NGW, it works fine
• I've tried using airmon-ng check kill and airmon-ng start wlan0 or start-mon.sh script from this repo, issue persists
• Managed mode works ok in basic iperf tests
• I tried using kismet

Did anyone successfully utilized this card it in monitor mode?
What's that warning from dmesg about iwpriv?

dmesg log, it keeps repeating when airodump-ng is running

[    7.353493] mt7925e 0000:00:10.0: WM Firmware Version: ____000000, Build Time: 20241104133053
## started: sudo airodump-ng wlan0
[  130.492401] warning: `iwpriv' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
[  134.235730] mt7925e 0000:00:10.0: Message 00020024 (seq 11) timeout
[  137.307711] mt7925e 0000:00:10.0: Message 00020024 (seq 12) timeout
[  140.379786] mt7925e 0000:00:10.0: Message 00020024 (seq 13) timeout
[  143.451904] mt7925e 0000:00:10.0: Message 00020008 (seq 14) timeout
[  143.542788] mt7925e 0000:00:10.0: HW/SW Version: 0x8a108a10, Build Time: 20241104132949a

[  143.887066] mt7925e 0000:00:10.0: WM Firmware Version: ____000000, Build Time: 20241104133053
[  147.803718] mt7925e 0000:00:10.0: Message 00020024 (seq 5) timeout
[  150.875960] mt7925e 0000:00:10.0: Message 00020024 (seq 6) timeout
[  153.947841] mt7925e 0000:00:10.0: Message 00020008 (seq 9) timeout
[  154.039624] mt7925e 0000:00:10.0: HW/SW Version: 0x8a108a10, Build Time: 20241104132949a

[  154.384421] mt7925e 0000:00:10.0: WM Firmware Version: ____000000, Build Time: 20241104133053
[  155.131725] mt7925e 0000:00:10.0 wlan0: entered promiscuous mode
[  155.167238] mt7925e 0000:00:10.0 wlan0: entered allmulticast mode
[  155.209134] mt7925e 0000:00:10.0: HW/SW Version: 0x8a108a10, Build Time: 20241104132949a
## repeats as long as airodump-ng is running

sometimes messages are a bit different:

[  168.723561] mt7925e 0000:00:10.0: WM Firmware Version: ____000000, Build Time: 20241104133053
[  172.639557] mt7925e 0000:00:10.0: Message 00020024 (seq 9) timeout
[  174.485787] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485803] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485805] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485808] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485810] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485813] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485815] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485817] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485819] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  174.485821] mt7925e 0000:00:10.0: swiotlb buffer is full (sz: 4096 bytes), total 32768 (slots), used 32768 (slots)
[  175.711601] mt7925e 0000:00:10.0: Message 00020024 (seq 10) timeout
[  175.818875] mt7925e 0000:00:10.0: HW/SW Version: 0x8a108a10, Build Time: 20241104132949a

[morrownr]

Hi @dbie0

I have one of the mt7925 M.2 card here. Let me see what I get. My system runs Ubuntu 24.10 and I'm on kernel 6.12.

BTW, with kernel 6.12, your BT will start working as that is the first kernel with the BT device ID.

[ZerBea]

@dbie0 What's that warning from dmesg about iwpriv?
The tool iwpriv and the entire Wireless Extensions suite is outdated and should not be used any longer on modern hardware.
The log of dmesg told you that:
iwpriv' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
Use nl80211 means that you should use state of the art tools like iw and ip instead of them.

More info is here:
https://en.wikipedia.org/wiki/Wireless_tools_for_Linux
and here:
https://www.geeksforgeeks.org/deprecated-linux-networking-commands-and-their-replacements/

[morrownr]

@ZerBea @dbie0

I just finished some light testing here.

The tool iwpriv and the entire Wireless Extensions suite is outdated...

I am not seeing that here so that must be the result of something besides the mt7925u driver. I agree that using the modern tools is what needs to be done... iw and ip.

What I did see is the interface going into monitor mode but something not exactly right as there were delays. It will take me some time to sort this out as I don't what is causing the problem. I do know that there are several patches in wireless-next ready to go into 6.14 and several have to do with the mt7925. Given that we do not have any USB adapters with this chip on the market yet, monitor mode testing has been limited. I'll be testing further and keeping an eye open.

@morrownr

[ZerBea]

@morrownr I fully agree.

Additional remarks:

Linux kernel 6.11.2 is EOL and has not received latest driver fixes:
https://www.kernel.org/

airmon-ng has been used to set monitor mode
started: sudo airodump-ng wlan0

And grep shows this on latest aircrack-ng git head:

$ grep -r iwpriv
apparmor/usr.sbin.easside-ng:  /sbin/iwpriv Cx,
apparmor/usr.sbin.easside-ng:  profile /sbin/iwpriv {
apparmor/usr.sbin.easside-ng:    /sbin/iwpriv mr,
apparmor/usr.sbin.wesside-ng:  /sbin/iwpriv Cx,
apparmor/usr.sbin.wesside-ng:  profile /sbin/iwpriv {
apparmor/usr.sbin.wesside-ng:    /sbin/iwpriv mr,
apparmor/usr.sbin.airbase-ng:  /sbin/iwpriv rCx,
apparmor/usr.sbin.airbase-ng:  profile /sbin/iwpriv {
apparmor/usr.sbin.airbase-ng:    /sbin/iwpriv mr,
apparmor/usr.sbin.airtun-ng:  /sbin/iwpriv Cx,
apparmor/usr.sbin.airtun-ng:  profile /sbin/iwpriv {
apparmor/usr.sbin.airtun-ng:    /sbin/iwpriv mr,
apparmor/usr.sbin.airserv-ng:  /sbin/iwpriv Cx,
apparmor/usr.sbin.airserv-ng:  profile /sbin/iwpriv {
apparmor/usr.sbin.airserv-ng:    /sbin/iwpriv mr,
apparmor/usr.sbin.aireplay-ng:  /sbin/iwpriv rCx,
apparmor/usr.sbin.aireplay-ng:  profile /sbin/iwpriv {
apparmor/usr.sbin.aireplay-ng:    /sbin/iwpriv mr,
apparmor/usr.sbin.tkiptun-ng:  /sbin/iwpriv Cx,
apparmor/usr.sbin.tkiptun-ng:  profile /sbin/iwpriv {
apparmor/usr.sbin.tkiptun-ng:    /sbin/iwpriv mr,
apparmor/usr.sbin.airodump-ng:  /sbin/iwpriv rCx,
apparmor/usr.sbin.airodump-ng:  profile /sbin/iwpriv {
apparmor/usr.sbin.airodump-ng:    /sbin/iwpriv mr,
ChangeLog:* airodump-ng & aireplay-ng: check of iwpriv existence
ChangeLog:    * airodump: ipw2200 didn't like calling "iwpriv ethX monitor 1"
ChangeLog:    * airodump: orinoco: fixed "iwpriv ethX monitor 1" command
lib/osdep/linux.c:	char * iwpriv;
lib/osdep/linux.c:		execl(path, "iwpriv", iface, "ndis_reset", NULL);
lib/osdep/linux.c:				execlp(dev->iwpriv,
lib/osdep/linux.c:					   "iwpriv",
lib/osdep/linux.c:				execlp(dev->iwpriv,
lib/osdep/linux.c:					   "iwpriv",
lib/osdep/linux.c:					execlp(dev->iwpriv,
lib/osdep/linux.c:						   "iwpriv",
lib/osdep/linux.c:					execlp(dev->iwpriv,
lib/osdep/linux.c:						   "iwpriv",
lib/osdep/linux.c:	/* couple of iwprivs to enable the prism header */
lib/osdep/linux.c:		execlp("iwpriv", "iwpriv", iface, "monitor_type", "1", NULL);
lib/osdep/linux.c:		execlp("iwpriv", "iwpriv", iface, "prismhdr", "1", NULL);
lib/osdep/linux.c:		execlp("iwpriv", "iwpriv", iface, "set_prismhdr", "1", NULL);
lib/osdep/linux.c:	dev->iwpriv = wiToolsPath("iwpriv");
lib/osdep/linux.c:	if (!(dev->iwpriv))
lib/osdep/linux.c:	/* Exit if ndiswrapper : check iwpriv ndis_reset */
lib/osdep/linux.c:	if (is_ndiswrapper(iface, dev->iwpriv))
lib/osdep/linux.c:				 "iwpriv %s 2>/dev/null | "
lib/osdep/linux.c:				 "iwpriv %s 2>/dev/null | "
lib/osdep/linux.c:				 "iwpriv %s rfmontx 1 >/dev/null 2>/dev/null",
lib/osdep/linux.c:			execlp("iwpriv", "iwpriv", iface, "get_port3", NULL);
lib/osdep/linux.c:				 "iwpriv %s 2>/dev/null | "
lib/osdep/linux.c:			execlp("iwpriv", "iwpriv", iface, "get_regdomain", NULL);
lib/osdep/linux.c:	if (pl->iwpriv) free(pl->iwpriv);

@dbie0
I suggest to remove Wireless Extensions completely so that the aircrack-ng suite can't start them-

[morrownr]

@dbie0

Dang. @ZerBea remembers things better than I do. He must being younger or smarter or both.

Your mt7925 based card is a WiFi 7 card. The Linux kernel has had code in it to refuse to operate WEXT api's once your are running WiFi 7. Aircrack-ng uses WEXT, which is long depreciated, so our kernel is refusing to run some functions.

We need to find a way to run what you want to run without Aircrack-ng.

Hey @ZerBea , would hcxdumptool work to do the test @dbie0 is trying to do?

https://github.com/ZerBea/hcxdumptool

Maybe you can get him going with it if you have time?

@dbie0

hcxdumptool is not a full featured pen testing tool as that is not what it was designed to do but it can let us know if monitor mode is working and injection is working. Plus we know the guy who works on it (wink wink).

It is not clear to me what new Aircrack-ng replacement is available so the search is on.

The bottomline is that you need to give up on Aircrack-ng. The Linux kernel is shutting parts of it down, as it is designed to do. The mt7925e driver may be working in monitor mode perfectly, we just don't know it.

[ZerBea]

It doesn't make sense to run further going tests on an EOL kernel. I suggest to update to latest kernel and to remove WEXT. Then we'll see what the dmesg log shows.
For this tests I also suggest to use iw and ip to set monitor mode. This minimizes possible sources of error.
And I don't recommend to use hcxdumptool/hcxlabtool if the requirements as mentioned in README.md are not met.

[morrownr]

@ZerBea

and to remove WEXT.

Do you know which packages need to be removed?

I have needed WEXT given that I work on old drivers but after thinking about it, I have one system where I could and should remove WEXT. I went to see what packages to delete and I could not find anything.

[ZerBea]

On Arch WEXT is named as wireless-tools:
https://archlinux.org/packages/extra/x86_64/wireless_tools

BTW:
hcxdumptool/hcxlabtool is not a full featured pen testing tool
Maybe. But if the requirements are met it can do magic.
Please, make up your own mind:
ZerBea/hcxdumptool#485 (comment)
ZerBea/hcxtools#349 (comment)
https://hashcat.net/forum/thread-7717.html

[dbie0]

@morrownr @ZerBea thanks for the support!
My use case isn’t anything serious—I’ve just been curious about Wi-Fi pen-testing for a while and wanted to explore it. So, when I needed to buy a Wi-Fi card, I looked for one that supports it and came across this repo and the MT7925.

I've tried setting the card to monitor mode with iw and ip, Proxmox VM, Ubuntu 24.10, kernel 6.12.9-zabbly+:

ip link set wls16 down
iw wls16 set monitor none 
ip link set wls16 up

Unfortunately, after setting the link up, dmesg is cluttered with timeout messages the same way as in the 1st comment.

Interestingly, when active or cook modes are used (no idea yet what those are), it seems to be working -> it brings interface up fast and withou dmesg messages. Other modes I've tested: none, fcsfail, control, and otherbss, seem to trigger the issue.
I tried to execute airodump-ng when the card is already in active or cooked mode, it behaves "more correctly", it switches channels fast, the same way as on an Intel card, still not capturing/outputting anything.

wireless-tools is not installed, marked as "Suggests" for aircrack-ng, but seems not even to be present in the repo.

I will ditch the Proxmox part, switch to bare-metal, retest switching with iw + ip, and try to capture some frames with hcxdumptool.

[dbie0]

I swapped the disk and found a Fedora 41 installation, so I ran tests on it using kernel 6.12.9-200.fc41.x86_64 and firmware version 20241104133053.
The behavior is the same as described earlier: the card can be set to “active” and “cook” modes without errors, but attempting other modes results in errors in dmesg. When the card is in “active” mode and I run hcxdumptool or hcxdumptool -A, there are no errors, but no packets are captured. In “none” mode with hcxdumptool running, errors are consistently reported in dmesg.

As a sanity check, I tested hcxdumptool with an Intel card, and it works. However, in “none” mode only, as “active” mode is not supported.

[ZerBea]

@dbie0 I will ditch the Proxmox part, switch to bare-metal, retest switching with iw + ip, and try to capture some frames with hcxdumptool.
First part is a very good idea, the last part not.

I don't recommend to use hcxdumptool, because it is a merciless interactive attack tool primary on CLIENTs but also on ACCESS POINTs.
Instead run either tshark or Wireshark to monitor / dump the WiFi traffic.
Additional you can run the netlink monitor interface (nlmon) to figure out whats going on during the communication of ip/iw with the kernel (by Wireshark):

$ sudo ip link add nlmon0 type nlmon
$ sudo ip link set dev nlmon0 up

Now you see a new monitor interface in Wireshark / tshark which is able to capture/dump the netlink traffic.

MT7925E hardware is relatively new and it is under heavy development.
https://patchwork.kernel.org/project/linux-wireless/list/
To get benefit of the recent changes it is mandatory to run the latest Linux kernel.

General information about WiFi driver is here:
https://wireless.docs.kernel.org/en/latest/en/users/drivers.html
and especially for Mediatek here:
https://wireless.docs.kernel.org/en/latest/en/users/drivers/mediatek.html

Unfortunately there are still several issues to fix, e.g.:
openwrt/mt76#926
openwrt/openwrt#16273
https://bugzilla.kernel.org/show_bug.cgi?id=219505
So it might be worth it to take a closer look at the latest mainline kernel 6.13-rc7 kernel, too.

[ZerBea]

@dbie0 I tested hcxdumptool with an Intel card, and it works.
Thanks for the test.
Usually Intel PCIe cards are known as not working. While monitor mode is fine, full packet injection failed:
there are several problems running this cards:
https://duckduckgo.com/?t=ffab&q=iwlwifi+packet+injection&ia=web
And packet injection is not mentioned here, only sniffer mode:
https://wireless.docs.kernel.org/en/latest/en/users/drivers/iwlwifi/debugging.html#how-to-get-a-sniffer-capture-with-your-intel-device

Official (by Intel) neither monitor mode nor packet injection is supported, e.g.
https://community.intel.com/t5/Wireless/How-to-enable-wireless-monitor-mode-in-Intel-Wireless-AC-9560/m-p/654032