hcxtools - solution for capturing wlan traffic and conversion to hashcat formats

[ZerBea]

Depends on the options, you used:
--use_gpsd -> if gpsd freeze, hcxdumptool will freeze, too

better choice:
---use_gps_device=your_device

make sure your device is working and has a fix:
$ cat your_device
you should receive non empty NMEA sentences

It is also possible, that the WiFi driver crashed (if you use an ath9k_htc device):
https://bugzilla.kernel.org/show_bug.cgi?id=198701
https://github.com/ZerBea/hcxdumptool/issues/80

If you're running a Raspberry Pi, make sure that WiFi device and GPS device power consumption doesn't exceed USB power limit. Maximum total USB peripheral current draw states the max USB current for Pi(2/B+) is 600/1200mA. The limit for Pi3 is 1200mA. Earlier models claim 500mA. If you don't take care about that, the RPi will freeze.

BTW:
I'm not a native english speaker, so my english isn't much better....

[strike1953]

Depends on the options, you used:
--use_gpsd  -> if gpsd freeze, hcxdumptool will freeze, too

better choice:
---use_gps_device=your_device

make sure your device is working and has a fix:
$ cat your_device
you should receive non empty NMEA sentences

It is also possible, that the WiFi driver crashed (if you use an ath9k_htc device):
https://bugzilla.kernel.org/show_bug.cgi?id=198701
https://github.com/ZerBea/hcxdumptool/issues/80Wifi

If you're running a Raspberry Pi, make sure that WiFi device and GPS device power consumption doesn't exceed USB power limit. Maximum total USB peripheral current draw states the max USB current for Pi(2/B+) is 600/1200mA. The limit for Pi3 is 1200mA. Earlier models claim 500mA. If you don't take care about that, the RPi will freeze.

BTW:
I'm not a native english speaker, so my english isn't much better....

My sentence is "hcxdumptool -i wlx00156d72f392 -o 11enero.pcapng --enable_status=1 --filterlist_ap=blacklist.txt --use_gps_device=/dev/ttyACM0 --nmea=test.nmea"

Ubuntu 18.04
Wifi Driver Ath9k
[img][/img]

[ZerBea]

Ok, now we know the cause: ath9k_htc driver
I have a TPL-LINK TL-WN722N V1 for testing purpose and it shows the same "ugly" behavior.
$ hcxdumptool -I
wlan interfaces:
f81a6718410f wlp3s0f0u2 (ath9k_htc)
$ lsusb
ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n

First, the driver is running fine.
$ dmesg
[80662.584198] usb 1-2: new high-speed USB device number 9 using xhci_hcd
[80662.841281] usb 1-2: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08
[80662.841285] usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[80662.841288] usb 1-2: Product: USB2.0 WLAN
[80662.841291] usb 1-2: Manufacturer: ATHEROS
[80662.841293] usb 1-2: SerialNumber: 12345
[80662.929928] usb 1-2: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[80662.929984] usbcore: registered new interface driver ath9k_htc
[80664.006390] usb 1-2: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
[80664.256290] ath9k_htc 1-2:1.0: ath9k_htc: HTC initialized with 33 credits
[80664.484941] ath9k_htc 1-2:1.0: ath9k_htc: FW Version: 1.4
[80664.484944] ath9k_htc 1-2:1.0: FW RMW support: On
[80664.484946] ath: EEPROM regdomain: 0x809c
[80664.484947] ath: EEPROM indicates we should expect a country code
[80664.484948] ath: doing EEPROM country->regdmn map search
[80664.484949] ath: country maps to regdmn code: 0x52
[80664.484951] ath: Country alpha2 being used: CN
[80664.484952] ath: Regpair used: 0x52
[80664.489654] ieee80211 phy2: Atheros AR9271 Rev:1
[80664.492932] ath9k_htc 1-2:1.0 wlp3s0f0u2: renamed from wlan0
...
but after a while, it died:
[80906.620423] ath: phy2: Short RX data len, dropping (dlen: 4)
[80906.623232] ath: phy2: Short RX data len, dropping (dlen: 4)
[80906.656349] ath: phy2: Short RX data len, dropping (dlen: 4)
[80906.656360] ath: phy2: Short RX data len, dropping (dlen: 4)
[80906.734921] ath: phy2: Short RX data len, dropping (dlen: 4)
[80906.756039] ath: phy2: Short RX data len, dropping (dlen: 4)
[80912.846741] ath: phy2: Short RX data len, dropping (dlen: 4)
[80912.869528] ath: phy2: Short RX data len, dropping (dlen: 4)
[80918.663242] ath: phy2: Short RX data len, dropping (dlen: 4)
[80918.783277] ath: phy2: Short RX data len, dropping (dlen: 4)
...
[81054.042301] ath: phy2: Short RX data len, dropping (dlen: 5)
[81054.053948] ath: phy2: Short RX data len, dropping (dlen: 4)
[81054.056381] ath: phy2: Short RX data len, dropping (dlen: 4)
...
and spams dmesg log.
At this time hcxdumptool will freeze.

And the whole system died:
Jan 13 16:48:10.888655 tux1 kernel: ------------[ cut here ]------------
Jan 13 16:48:10.888795 tux1 kernel: kernel BUG at mm/slub.c:306!
Jan 13 16:48:10.888894 tux1 kernel: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
Jan 13 16:48:10.888982 tux1 kernel: CPU: 4 PID: 82264 Comm: hcxdumptool Tainted: P C OE 5.4.10-arch1-1 #1
Jan 13 16:48:10.889027 tux1 kernel: Hardware name: Micro-Star International Co., Ltd. MS-7A33/X370 KRAIT GAMING (MS-7A33), BIOS 1.F0 11/06/2018
Jan 13 16:48:10.889064 tux1 kernel: RIP: 0010:__slab_free+0x262/0x460
Jan 13 16:48:10.889098 tux1 kernel: Code: 00 00 4d 85 c0 0f 85 da 00 00 00 80 7c 24 6b 00 79 09 45 84 c9 0f 84 a5 00 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 80 4c 24 6b 80 e9 86 fe ff ff 44 88 5c 24 3b 4c 89 44 24 08
Jan 13 16:48:10.889145 tux1 kernel: RSP: 0018:ffffbd018156bac0 EFLAGS: 00010246
Jan 13 16:48:10.889180 tux1 kernel: RAX: ffffa1792b147c00 RBX: 000000008020001e RCX: ffffa1792b147c00
Jan 13 16:48:10.889215 tux1 kernel: RDX: ffffa1792b147c00 RSI: ffffe4c9ceac5100 RDI: ffffa1798d006d80
Jan 13 16:48:10.889252 tux1 kernel: RBP: ffffbd018156bb70 R08: 0000000000000001 R09: ffffffffa716dd82
Jan 13 16:48:10.889287 tux1 kernel: R10: ffffa17988a71ed8 R11: ffffa1798edaab38 R12: ffffe4c9ceac5100
Jan 13 16:48:10.889321 tux1 kernel: R13: ffffa1792b147c00 R14: ffffa1792b147c00 R15: ffffa1798d006d80
Jan 13 16:48:10.889356 tux1 kernel: FS: 00007f04a2898b80(0000) GS:ffffa1798ed00000(0000) knlGS:0000000000000000
Jan 13 16:48:10.889391 tux1 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 13 16:48:10.889431 tux1 kernel: CR2: 0000560ae2242018 CR3: 00000003adfde000 CR4: 00000000003406e0
Jan 13 16:48:10.889466 tux1 kernel: Call Trace:
Jan 13 16:48:10.889504 tux1 kernel: ? _raw_spin_unlock_irqrestore+0x20/0x40
Jan 13 16:48:10.889532 tux1 kernel: ? try_to_wake_up+0x7a/0x750
Jan 13 16:48:10.889565 tux1 kernel: ? wake_up_q+0x3b/0x60
Jan 13 16:48:10.889599 tux1 kernel: ? ath9k_wmi_cmd+0x1a0/0x1c0 [ath9k_htc]
Jan 13 16:48:10.889634 tux1 kernel: kfree_skb+0x32/0xb0
Jan 13 16:48:10.889668 tux1 kernel: ath9k_wmi_cmd+0x1a0/0x1c0 [ath9k_htc]
Jan 13 16:48:10.889702 tux1 kernel: ath9k_htc_config+0x18b/0x620 [ath9k_htc]
Jan 13 16:48:10.889736 tux1 kernel: ieee80211_hw_config+0x7f/0x3c0 [mac80211]
Jan 13 16:48:10.889775 tux1 kernel: ieee80211_set_monitor_channel+0xf9/0x130 [mac80211]
Jan 13 16:48:10.889810 tux1 kernel: cfg80211_set_monitor_channel+0x72/0x180 [cfg80211]
Jan 13 16:48:10.889844 tux1 kernel: cfg80211_wext_siwfreq+0x10a/0x130 [cfg80211]
Jan 13 16:48:10.889878 tux1 kernel: ioctl_standard_call+0x4c/0x100
Jan 13 16:48:10.889917 tux1 kernel: wext_handle_ioctl+0xc2/0x120
Jan 13 16:48:10.889955 tux1 kernel: sock_ioctl+0x290/0x3f0
Jan 13 16:48:10.889993 tux1 kernel: do_vfs_ioctl+0x43d/0x6c0
Jan 13 16:48:10.890026 tux1 kernel: ? syscall_trace_enter+0x19c/0x2e0
Jan 13 16:48:10.890061 tux1 kernel: ksys_ioctl+0x5e/0x90
Jan 13 16:48:10.890092 tux1 kernel: __x64_sys_ioctl+0x16/0x20
Jan 13 16:48:10.890130 tux1 kernel: do_syscall_64+0x4e/0x140
Jan 13 16:48:10.890164 tux1 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jan 13 16:48:10.890198 tux1 kernel: RIP: 0033:0x7f04a29b725b
Jan 13 16:48:10.890233 tux1 kernel: Code: 0f 1e fa 48 8b 05 25 9c 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f5 9b 0c 00 f7 d8 64 89 01 48
Jan 13 16:48:10.890268 tux1 kernel: RSP: 002b:00007ffff26689e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
Jan 13 16:48:10.890303 tux1 kernel: RAX: ffffffffffffffda RBX: 0000555b6943a760 RCX: 00007f04a29b725b
Jan 13 16:48:10.890337 tux1 kernel: RDX: 0000555b693f84c0 RSI: 0000000000008b04 RDI: 0000000000000003
Jan 13 16:48:10.890371 tux1 kernel: RBP: 0000555b693f8180 R08: 0000000000000004 R09: 0032753066307333
Jan 13 16:48:10.890402 tux1 kernel: R10: 0000000000000020 R11: 0000000000000246 R12: 0000555b6943a770
Jan 13 16:48:10.890439 tux1 kernel: R13: 0000555b693f72a0 R14: 0000000000002401 R15: 0000000000000003
Jan 13 16:48:10.890474 tux1 kernel: Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mt76x0u mt76x0_common mt76x02_usb mt76_usb mt76x02_lib mt76 mac80211 libarc4 r8188eu(C) lib80211 uas usb_storage nvidia_uvm(OE) fuse cfg80211 rfkill 8021q garp mrp stp snd_hda_codec_hdmi llc nvidia_drm(POE) nvidia_modeset(POE) edac_mce_amd ppdev wmi_bmof mxm_wmi nvidia(POE) snd_hda_codec_realtek kvm snd_hda_codec_generic ledtrig_audio irqbypass snd_hda_intel nls_iso8859_1 snd_intel_nhlt snd_hda_codec nls_cp437 drm_kms_helper vfat snd_hda_core snd_hwdep fat crct10dif_pclmul crc32_pclmul drm snd_pcm r8169 ghash_clmulni_intel agpgart realtek ipmi_devintf aesni_intel ccp snd_timer ipmi_msghandler sp5100_tco snd syscopyarea crypto_simd parport_pc sysfillrect cryptd sysimgblt mousedev input_leds fb_sys_fops libphy glue_helper soundcore pcspkr rng_core k10temp i2c_piix4 parport wmi pinctrl_amd gpio_amdpt evdev mac_hid acpi_cpufreq sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 hid_generic usbhid hid
Jan 13 16:48:10.890537 tux1 kernel: sr_mod cdrom sd_mod ahci libahci libata xhci_pci crc32c_intel scsi_mod xhci_hcd [last unloaded: 8812au]
Jan 13 16:48:10.890574 tux1 kernel: ---[ end trace 86bae3dfd85f4aad ]---

[strike1953]

but with the previous hcxdumptool I had no problems

[img][/img]

[ZerBea]

That isn't a dmesg log while hcxdumptool is running. Your log is showing NetworkManager access to the device.

As you can see from my dmesg log:
Jan 13 16:48:10.888795 tux1 kernel: kernel BUG at mm/slub.c:306!
Jan 13 16:48:10.888894 tux1 kernel: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
Jan 13 16:48:10.888982 tux1 kernel: CPU: 4 PID: 82264 Comm: hcxdumptool Tainted: P C OE 5.4.10-arch1-1 #1

The driver didn't accept commands from hcxdumptool any longer and crashed. The workload is too high for the driver.

[strike1953]

Too bad, I'll have to go back to the old hcxdumptool since Version 6 is not compatible with my hardware. I will not be able to enjoy the benefits of the hash 22000

[ZerBea]

hashmode is independent from hcxdumptool. You can use hcxpcangtool on that pcapng files to convert them.
I'm still hunting for that kernel bug, like other coders, too:
https://bugzilla.kernel.org/buglist.cgi?...%2Fslub%20
https://bugzilla.redhat.com/show_bug.cgi?id=1743043
https://bugzilla.redhat.com/show_bug.cgi?id=1777601
https://lists.gt.net/linux/kernel/3390507

[strike1953]

Thank you very much your for your attention and congratulations for these tools.

[ZerBea]

As of today, only mt76 and rt2800usb driver families are working without issues.

[strike1953]

As of today, only mt76 and rt2800usb driver families are working without issues.

They do not provide the power and benefits of the Wifistation Planar