hcxdumptool: hcxdumptool freezes everything after few seconds
Every few days I update all the utilities in my system. And after the last update, hcxdumptool stopped working.
That is, when I try to start as usual
hcxdumptool -i wlan1 --reactive --enable_status 31 -o manual_a9.pcapng
It works the first 5-10 seconds and freezes. I cannot close using Ctrl + C and the iwconfig command is not responding. Everyone wifi commands stops normal working. Everything becomes normal again when I disconnect the wifi adapter.
Having rolled back to the version from the kali repository, everything works fine there.
I checked these commands
hcxdumptool -I
hcxdumptool -i wlan1 --check_driver
hcxdumptool -i wlan1 --do_rcascan
Everything is fine here.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 60 (38 by maintainers)
Commits related to this issue
- removed TP-LINK TL-WN722N v1 due to driver issues — committed to ZerBea/hcxdumptool by ZerBea 4 years ago
Yes, you’re right. That is an xhci (USB host) issue and it affect several devices. The ath9k issue (driver and firmware) seems to be solved.
Looks like we can expect an ath9k_htc fix on kernel 5.5. Two patches are merged: https://bugzilla.kernel.org/show_bug.cgi?id=198701#c5 If it works like expected, we can expect that both patches are ported back to LTS-Kernels.
Some words about tx power, beside this ones here: https://metis.fi/en/2017/10/txpower/
It is a fairytale that increasing tx power will lead to more results! https://en.wikipedia.org/wiki/DBm "A power level of 0 dBm corresponds to a power of 1 milliwatt. A 10 dB increase in level is equivalent to a 10-fold increase in power. A 3 dB increase in level is approximately equivalent to doubling the power, which means that a level of 3 dBm corresponds roughly to a power of 2 mW. Similarly, for each 3 dB decrease in level, the power is reduced by about one half, making −3 dBm correspond to a power of about 0.5 mW. "
A good antenna is the best hf amplifier: https://www.arrl.org/files/file/Technology/tis/info/pdf/9811054.pdf
Increasing tx power will make the signal crappy! A spectrum analyzer will show you this.
… and thousands of more good reasons.
If you “blacklisted” the device by “NetworkManager config” and the driver issue is still present, we must wait for the kernel driver fix.
The RT3070 uses the rt2800usb driver. It will work fine if you make sure that NetworkManager can’t access the device (by adding the device mac to NetworkManager config). It will not work if you connect the device to an USB3 port especially on an AMD RYZEN motherboard. In that case you will run into this kernel issue (not fixed, yet): https://bugzilla.kernel.org/show_bug.cgi?id=202541
Here is an example of this issue: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter dmesg log: [ 43.907984] usb 1-2: new high-speed USB device number 6 using xhci_hcd [ 44.064919] usb 1-2: New USB device found, idVendor=148f, idProduct=3070, bcdDevice= 1.01 [ 44.064928] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 44.064934] usb 1-2: Product: 802.11 n WLAN [ 44.064940] usb 1-2: Manufacturer: Ralink [ 44.064944] usb 1-2: SerialNumber: 1.0 [ 44.725138] usb 1-2: reset high-speed USB device number 6 using xhci_hcd [ 44.876642] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected [ 44.893423] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0005 detected [ 44.894231] ieee80211 phy1: Selected rate control algorithm ‘minstrel_ht’ [ 44.904724] usbcore: registered new interface driver rt2800usb [ 44.958162] audit: type=1130 audit(1575358746.711:35): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=systemd-rfkill comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’ [ 45.025041] rt2800usb 1-2:1.0 wlp0s20f0u2: renamed from wlan0 [ 45.092238] ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading firmware file ‘rt2870.bin’ [ 45.126266] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 [ 45.435450] ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 [ 46.467853] ieee80211 phy1: rt2800_wait_csr_ready: Error - Unstable hardware [ 46.467866] ieee80211 phy1: rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5)
The same device, connected to an USB2 port of the same notebook is working fine: [ 1839.849738] usb 1-3: new high-speed USB device number 9 using xhci_hcd [ 1840.008305] usb 1-3: New USB device found, idVendor=148f, idProduct=3070, bcdDevice= 1.01 [ 1840.008315] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1840.008321] usb 1-3: Product: 802.11 n WLAN [ 1840.008326] usb 1-3: Manufacturer: Ralink [ 1840.008331] usb 1-3: SerialNumber: 1.0 [ 1840.137020] usb 1-3: reset high-speed USB device number 9 using xhci_hcd [ 1840.288016] ieee80211 phy4: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected [ 1840.300254] ieee80211 phy4: rt2x00_set_rf: Info - RF chipset 0005 detected [ 1840.300882] ieee80211 phy4: Selected rate control algorithm ‘minstrel_ht’ [ 1840.321054] rt2800usb 1-3:1.0 wlp0s20f0u3: renamed from wlan0 [ 1869.514883] ieee80211 phy4: rt2x00lib_request_firmware: Info - Loading firmware file ‘rt2870.bin’ [ 1869.514906] ieee80211 phy4: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36 [ 1869.769893] device wlp0s20f0u3 entered promiscuous mode [ 1869.770056] audit: type=1700 audit(1575360571.519:168): dev=wlp0s20f0u3 prom=256 old_prom=0 auid=1000 uid=0 gid=0 ses=2 [ 1876.139841] device wlp0s20f0u3 left promiscuous mode [ 1876.139872] audit: type=1700 audit(1575360577.889:169): dev=wlp0s20f0u3 prom=0 old_prom=256 auid=1000 uid=0 gid=0 ses=2 [ 1876.161908] audit: type=1106 audit(1575360577.909:170): pid=1404 uid=0 auid=1000 ses=2 msg=‘op=PAM:session_close grantors=pam_limits,pam_unix,pam_permit acct=“root” exe=“/usr/bin/sudo” hostname=? addr=? terminal=/dev/pts/1 res=success’
As of today and kernel 5.3.13 most of the drivers are not(!) working out of the box due to several driver issues (especially under heavy workload), depending on the hardware configuration (e.g. USB3, VENDOR). Or they don’t support monitor mode. If issues are reported on https://bugzilla.kernel.org and/or https://github.com/openwrt/mt76/issues and for rtl8812au on https://github.com/aircrack-ng/rtl8812au/issues
Some of them are fixed in latest kernel versions: https://bugzilla.kernel.org/show_bug.cgi?id=202241 https://bugzilla.kernel.org/show_bug.cgi?id=202243 https://bugzilla.kernel.org/show_bug.cgi?id=205305 https://github.com/openwrt/mt76/issues/216#issuecomment-500999516 but many, many of them are still unfixed.
It it is very fragile and really hard work to get a driver working like expected (monitor mode inclusive full packet injection). A single update/commit can destroy the driver. Here is a good example https://github.com/aircrack-ng/rtl8812au/issues/499
That is the reason, why I removed several adapters (formerly known as working) from the list of working devices: https://github.com/ZerBea/hcxdumptool/wiki/WiFi-Adapters