hcxtools - solution for capturing wlan traffic and conversion to hashcat formats
Your assumption is correct. I noticed that, too.
Some devices probe their entire NVRAM to hcxdumptool:
Code:
NVRAM
NVRAM WARNING
NVRAM WARNING: ERR 0x10
NVRAM WARNING: Err = 0x01
NVRAM WARNING: Err = 0x02
NVRAM WARNING: Err = 0x06
NVRAM WARNING: Err = 0x10
NVRAM WARNING: Err = 0x1p
NVRAM WARNING: Err=7x13
NVRAM WARNING: Errel WiFi
NVRAMERROR
NVRAM_Err_0x10
Reply
hi zerbea, hope all is good, sorry for this question not really related to hashcat or hcxdumptool.just a curiosity, will hcxdumptool work with ath10k driver, i really don't get that. some say that injection work some not. i never buy a device if hcxdumptool does not work, lol.
Reply
I'm fine, thanks and I hope you're fine, too.
First a general answer:
hcxdumptool is working on every driver (e.g.: mt76, rt2800usb, ath9k) that is able to run full monitor mode, full packet injection, accept ioctl() system calls and doesn't depend on NETLINK.
Unfortunately some drivers are hit by issues that (e.g. freeze/timeout on ath9k):
https://bugzilla.kernel.org/show_bug.cgi?id=207397

Now to answer your question: atk10k will not work due to firmware/driver limitations:
https://wireless.wiki.kernel.org/en/user...ers/ath10k
Code:
firmware does not support association to the same AP from different virtual STA interfaces (driver prints “ath10k: Failed to add peer XX:XX:XX:XX:XX:XX for VDEV: X” in that case)
packet injection isn't supported yet
applying ath9k regulatory domain hack patch from OpenWRT causes firmware crash (reason: regulatory hint function is never called and ath10k never sends scan channel list to the firmware which in turn causes firmware to crash on scan)
tx rate is reported as 6mbps due to firmware limitation (no tx rate information in tx completions); instead see /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats
WEP doesn't work with AP_VLANs - frames are sent unencrypted (observed on: 999.999.0.636, 10.2.4.20-1, 10.1.467.2-1)
TX speeds are extremely poor on certain chips (QCA6174 is one). A patch solves the issue in most cases

Please notice:
We are talking about Linux kernel stock firmware/drivers
https://git.kernel.org/pub/scm/linux/ker...rmware.git
https://git.kernel.org/pub/scm/linux/ker...h=v5.10.15
and not about third party firmware/drivers/patches included in special penetration testing distributions (e.g.: K A L I).
BTW:
I do not use K A L I , because I'm not a penetration tester!

I fully agree:
I'll never buy a device if I know that the kernel stock driver doesn't support full monitor mode, full packet injection and ioctl() system calls.
But some times I get a device to test some third party drivers, e.g. new rtw88 stack (Realtek):
https://github.com/kimocoder/realtek_rtwifi
If you are a Linux newbee (or an unexperienced K A L I user), I can't recommend to use third party or patched firmware/drivers, because you'll run into several issues (at the latest on a kernel update).

A good start to get an information about driver, driver updates, issues and chipset:
https://wireless.wiki.kernel.org/en/users/Drivers
https://patchwork.kernel.org/project/lin...less/list/
https://bugzilla.kernel.org/
https://deviwiki.com/wiki/

But be warned: Manufacturers often change the chipset, but will use the same case and customary packing!
Reply
Hello ZerBea, when using hcxeiutool -h command and following the example listed at the bottom of the help, the last line of the example where it runs hashcat, is the "dump.pcapng" supposed to be "test.22000" instead?

I'm assuming so, unless I'm missing something important.  Thanks.
Reply
Hi walterlacka.
Thanks for reporting that ugly copy and paste error.
Fixed by this commit:
https://github.com/ZerBea/hcxtools/commi...28af54dbf6
Reply