hcxdumptool not working on Archlinux Kernel 6.13.1 / iwlwifi / Wireless 8265 / 8275

[DaniloNC]

Upgraded the archlinux kernel to 6.13.1 and after that the monitor interface hcxdumptool -i INTERFACE does not display any network, neither does tcpdump capture any packet in monitor mode (tested both with hcxdumptool -M and iw dev XXX set type [info.txt](https://github.com/user-attachments/files/18649894/info.txt) monitor

I rebooted and tested the lts kernel version (6.12), which is working fine.
I have a different machine that has Wi-Fi 6 AX200 and 6.13.1 is working fine there.

How can I get the Linux 6.13.1, hcxdumptool and Wireless 8265 / 8275 to play well together?
Anyone else facing similar issues?

Workaround for now is to run the lts kernel.

info.txt

[ZerBea]

That looks like a driver issue.
During the last past weeks, numerous changes have been made on iwlwifi
https://patchwork.kernel.org/project/linux-wireless/list/?state=*&archive=both&param=3&page=1
It looks like one of them broke the driver (monitor mode and/or packet injection).

How can I get the Linux 6.13.1, hcxdumptool and Wireless 8265 / 8275 to play well together?
To identify the faulty commit, I suggest to bisect the Linux kernel:
https://bbs.archlinux.org/viewtopic.php?id=271926
https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html
Once it has been identified report the regression as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

Anyone else facing similar issues?
Unfortunately yes. That is the reason why I mentioned in README.md:

Not recommended WiFi chipsets:
* Intel (Monitor mode and frame injection problems.)
* Broadcom (Neither monitor mode nor frame injection by official Linux kernel.)
* Qualcomm (No frame injection by official Linux kernel.)

Absolutely not recommended:
* All kinds of WiFi PCIe cards, due to massive interference.

[ZerBea]

To get more information, you can enable hcxdumptool's debug mode.
Uncomment HCXDEBUG in Makefile:

# uncomment to enable DEBUG log
#DEFS		+= -DHCXDEBUG

run make and start hcxdumptool:
$ ./hcxdumptool .....
Now, additional ERROR messages (coming from kernel, driver, hcxdumptool) are stored in "hcxdumptool.log".
Maybe this is useful to identify the driver regression.

[DaniloNC]

Thanks, @ZerBea!

I’d prefer not to mess with my current OS installation or repeatedly recompile the kernel on my aging 8th-gen i7. Instead, I’ll likely replace the wireless card with one that supports monitor mode and packet injection, then reproduce and debug the issue later on a different machine.

That said, recompiling hcxdumptool with debug enabled seems like a solid first step before diving into a kernel bisect. I’ll give it a shot when I have the time.

[ZerBea]

Don't be afraid to bisect the Linux kernel. Running Arch Linux, this is very simple:

1. enable bisect
2. compile kernel (using latest Arch kernel config)
3. build PKG
4. install PKG additional to your Linux and Linux-LTS kernel
5. choose the RC kernel on next boot
6. test interface
7. bisect next commit
8. goto 2

Please consider to buy an USB 2 adapter instead of an internal device.
Since Linux kernel 6.6 a new player has entered the field: rtl8xxxu
It has opened up the world to cheap hardware:

• TP-Link TL-WN722N (V2/3) in combination with a high gain panel antenna
• TP-Link TL-WN822N
• TP-Link TL-WN823N
  As of today, I use them as reference hardware to test new functions and to identify vulnerabilities on my test targets.

BTW:
I do not recommend to use:

• USB3 adapters
• Combined WiFi & BT adapters
• WiFi 5,6,7 (AC & AX) adapters
• high TX power adapters
• internal WiFi cards
• on-board WiFi chips
  Sooner or later you will have problems with it.

[DaniloNC]

Compiled the latest git commit with debug enabled, nothing in the log files:
https://asciinema.org/a/MIlIpclfQYQMLChb8FpnXuOB1

[ZerBea]

Thanks for sharing the screen record.
Looks like monitor mode is completely broken. The driver doesn't even send error messages.

[ZerBea]

To make sure the problem is not related to the general mac80211 stack or hcxdumptool, I did a test:

$ uname -r
6.13.1-arch1-1

$ lsusb
Bus 005 Device 003: ID 2357:010c TP-Link TL-WN722N v2/v3 [Realtek RTL8188EUS]

$ sudo hcxdumptool --rcascan=active --tot=1
...
2065 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1043 PROBERESPONSE(s) captured

exit on TOT

Running "--rcascan=active" hcxdumptool counts all PROBERESPONSEs directed to it.
Everything is working as expected (all test targets respond to hcxdumptool) running a TP-Link TL-WN722N as reference.