Replies: 13 comments 12 replies
-
|
That looks like a driver issue. How can I get the Linux 6.13.1, hcxdumptool and Wireless 8265 / 8275 to play well together? Anyone else facing similar issues? |
Beta Was this translation helpful? Give feedback.
-
|
To get more information, you can enable hcxdumptool's debug mode. run make and start hcxdumptool: |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Don't be afraid to bisect the Linux kernel. Running Arch Linux, this is very simple:
Please consider to buy an USB 2 adapter instead of an internal device.
BTW:
|
Beta Was this translation helpful? Give feedback.
-
|
Compiled the latest git commit with debug enabled, nothing in the log files: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing the screen record. |
Beta Was this translation helpful? Give feedback.
-
|
To make sure the problem is not related to the general mac80211 stack or hcxdumptool, I did a test: Running "--rcascan=active" hcxdumptool counts all PROBERESPONSEs directed to it. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like other users are affected, too: |
Beta Was this translation helpful? Give feedback.
-
|
Interesting, I don't have problems when using 6.12 / arch-lts. (https://archlinux.org/packages/core/x86_64/linux-lts/) Wondering if fedora back ported something from 6.13. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like the 8260 (rev 3a) is a little different to the 8265 / 8275: |
Beta Was this translation helpful? Give feedback.
-
|
I recently had some free time and decided to test the new Arch Linux kernel version 6.13.3; unfortunately, the issue persists. Consequently, I manually configured monitor mode using the I can confirm that manually setting the interface to monitor mode was successful. The commands I used were: With this setup, I was able to generate .22000 files in a controlled environment and successfully recover passwords. Is there anything I can assist with to discover why the interface configured by hcxdumptool is failing? |
Beta Was this translation helpful? Give feedback.
-
|
dmesg of hcxdumptool iw phy phy0 interface add + hcxdumptool -i mon0 iw dev - hcxdump monitor interface sudo iw --debug phy phy0 interface add mon0 type monitor |
Beta Was this translation helpful? Give feedback.
-
|
If you decide to try it, just change the code here: To: NL80211_CMD_NEW_INTERFACE (7) and add a VIF name. |
Beta Was this translation helpful? Give feedback.
-
|
Last but not least. create VIF by kismet: Please remember: kismon0 == great VIF for a passive sniffer. Run hcxdumptool on it: but unusable for an active ATTACK tool! |
Beta Was this translation helpful? Give feedback.
-
|
You can create a fork of hcxdumptool and apply your patch. I`ll do a git clone of your patched fork and give it a try. |
Beta Was this translation helpful? Give feedback.
-
|
I’d like to get your thoughts on what works best with iwlwifi on kernel 6.13.3 in my case, I also have some other usb and pcie cards I could test (using other drivers / chipsets) By default, the interface fails when I try: However, the following manual approach works: Instead of creating an additional VIF, I would like to try implementing:
This at least improves the iwlwifi but I wonder if that can break other drivers. |
Beta Was this translation helpful? Give feedback.
-
|
If you think this is merely a workaround for iwlwifi specific cases, I can simply provide hcxdumptool with my monitor interface (despite the README recommendation against it) and move forward with it. I'm mainly wondering if this approach would offer better stability across different chipsets and drivers beyond iwlwifi. |
Beta Was this translation helpful? Give feedback.
-
|
What is hcxdumptool/hcxlabtool doing:
In both cases NETLINK (set monitor mode) and RTNETLINK (bring interface up) is used. This is by far the most likely to succeed on modern systems. Conclusion: Intel chipset
Absolutely no word about packet injection: VIF
If you run a passive sniffer on an additional VIF (in monitor mode), it works as expected: Packet injection on an additional VIF (running in monitor mode) fails epically: A workaround for Intel chipsets (iwlwifi) will mess up all the other drivers (Ralink, Realtek, MediaTek) which adhere to the standard API (NETLINK and RTNETLINK). Intel is not(!) interested in monitor mode, so don't expect firmware updates regarding monitor mode and packet sniffing! On quit, delete the monitor interface and recreating the managed interface. (If that was the case before starting hcxdumptool)
But adding it to README.md is against all my recommendations: README.md That prevent a lot of issue reports itf the iw/ip way is not working in future times any longer. Feel free to open a new discussion (e.g. hcxdumptool and Intel chipsets) and explain your way to handle Intel chipsets. Run tshark in parallel on a second hardware interface to make sure that the Intel interface is really transmitting all kind of packets generated by hcxdumptool. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your input! Closing the discussion. |
Beta Was this translation helpful? Give feedback.
-
|
You're welcome. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Upgraded the archlinux kernel to 6.13.1 and after that the monitor interface
hcxdumptool -i INTERFACEdoes not display any network, neither does tcpdump capture any packet in monitor mode (tested both withhcxdumptool -Mandiw dev XXX set type [info.txt](https://github.com/user-attachments/files/18649894/info.txt) monitorI 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
Beta Was this translation helpful? Give feedback.
All reactions