hcxdumptool freezes everything after few seconds #80
Comments
LowSkillDeveloper
changed the title
|
Please add the output of BTW: |
|
This is on my RPi 4 |
|
This is on my Virtualbox on PC |
|
I tried another adapter on same chipset. And this not works. And if you start hcxdumptool first, and then even if you manage to stop it, then wifite, etc. Do not see anymore networks. |
|
hcxdumptool 5.2.2 works fine. |
|
Thanks for the information. dmesg show you two driver errors first one from here: second one from here: Make sure that NetworkManager doesn't have access to the device. Read more about how to prevent this, here: The other issue is already reported on kernel.org: |
|
Here are my logs (NetworkManager doesn't have access to the device): $ hcxdumptool -I dmesg log: and hcxdumptool works like expected - until I get hit by the driver issue. BTW |
|
Okay, as I understand, we can only wait for the driver will be fixed? And I recently ordered myself a Ralink RT3070. It will work fine with him? |
|
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). Here is an example of this issue: The same device, connected to an USB2 port of the same notebook is working fine: 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. Some of them are fixed in latest kernel versions: 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 That is the reason, why I removed several adapters (formerly known as working) from the list of working devices: |
|
Some words about tx power, beside this ones here: It is a fairytale that increasing tx power will lead to more results! A good antenna is the best hf amplifier: Increasing tx power will make the signal crappy! A spectrum analyzer will show you this. ... and thousands of more good reasons. |
|
Just compiled kernel 5.4 and the driver issue is still present: $ lsusb $ hcxdumptool -I $ dmesg Unfortunately 5.4 is a LTS kernel. |
|
Any distro which has a non-buggy/fixed kernel by default currently? |
|
I don't suppose. Not even Arch (rolling release) has a fix. |
|
Which is the latest kernel without the issue, 4.19 ? |
|
4.19.86 is running fine here: |
|
Looks like we can expect an ath9k_htc fix on kernel 5.5. Two patches are merged: |
|
I can reproduce that freeze: Possible fix for that kernel issue: (another two patches commited): |
|
Now removed TP-LINK TL-WN722N v1 from the "device known as working list" due to driver issues. |
|
Hello. This happened to me with latest Kali 2020.3. But when I updated to the kernel 5.8 it stopped happening. Maybe this got fixed? |
|
@gonzabrusco hello. Please comment output of BTW |
|
|
Great, thanks. Everything is looking fine, now. |
|
After some tests on I still can't recommend an ath9k_htc interface. We are running into a kernel issue that caused the driver after a while to freeze: This is a known issue and it is still unfixed: |
|
Fair enough. But reading the link you sent I come to the conclusion that this bug is not related to this adapter in particular. It seems like a bigger problem affecting several devices. |
|
Yes, you're right. That is an xhci (USB host) issue and it affect several devices. |
|
Thanks @ZerBea |
|
First of all: you can't compare airodump-ng with hcxdumptool because To identify the issue open 2 terminals. We only need the line from dmesg log after you plugged in the device. The lines between "entered promiscuous mode" and "left promiscuous mode" are important, because they tell us what happened. |
|
The problem is that when hcxdumptool stops working, DMESG also stops responding. I have to eject the TL-WN722 to make it work again. This is the result (It freezes and I have to pull the usb wifi adapter at the end): This is the dmesg (after pulling the usb wifi adapter): Looks like the problem is "ath: phy0: Unable to set channel" |
|
Something disconnect your USB device permanently and hcxdumptool retry to set monitor mode At least hcxdumptool give up and print an error message that your network went down. Now you have to find out, what exactly disconnect your USB device. I assume it is your VM or a tool which take access to the device. |
|
Those are because I run the check_driver and check_injection before running your command. |
|
This is the result again without running those commands before: It freezed again. So I had to pull the usb adapter again to be able to print dmesg. If I don't manually plug the USB adapter, dmesg does not work. It hangs. Something is hanging very badly but I cannot see exactly why. But this happens when I run hcxdumptool only. It there any "more verbose" mode? or maybe a development version I can try. |
|
I can reproduce that running my TP-LINK TL--WN722N. After a while and under heavy load (as hcxdudmptool produce it), the driver died. |
|
I changed my VMWARE virtual machine setting from usb 2.0 to usb 3.1 and now it's working (for now). I will let you know if it fails again. Thanks! |
|
That may one problem, but there is another one. |
|
It finally freezed again. But after much longer time. I don't know if it was a coincidence. This is dmesg (after pulling the usb adaptar): There's another error not related (vmtools) but the ath: phy0: Unable to set channel appeared again. |
|
After some investigations, it looks like we are running into a (well known) driver issue: After doing some DuckDuckGo searches, I noticed that the issue is well known for a long time. https://bugs.archlinux.org/task/68578 I try to add some code to hcxdumptool to detect this driver issue and to terminate hcxdumptool on this error. |
|
By latest commits |
see changelog for more details |
|
Now the issue is moved to bugzilla.kernel.org: @gonzabrusco can you confirm that hcxdumptool (latest git head) no longer freezes when the ath9k driver died? |
|
I don't expect a "quick solution": |
|
I tried it a few times. It always hangs. Sorry. Only one time it showed me this: "driver is busy: failed to transmit proberesponse" but it hanged nevertheless. I'm using this as OS on WMWare with Windows 10 as host: https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-image-download/ (Kali Linux VMware 64-Bit (7z)) Sometimes it works for a couple of seconds before it hangs, sometimes it works for minutes. But always the led stops blinking and it freezes. The error message you added does not always shows up. Dmesg stops responding so I have to pull the adapter to see it. But it does not show anything relevant really. I'm not sure why it is freezing. |
|
I'm now thinking in buying a Tp Link Archer T2uh because this 722N is having too many driver problems. Can you recommend that adapter? |
|
It is not easy to recommend a special device. Running into issues or not is driven by many different factors:
My preferred devices are running a mt76 chipset and/or a RT2870/RT3070 chipset. Also you should know that issues could happen - and we have had lots of them: |
|
Thanks @ZerBea . I think I will try my luck with that adapter. I tried again my TP-LINK TL-WN722N v1 with a live Kali from USB (without virtual machine) and it fails too. It just hangs. No warning from hcxdumptool. Dmesg also hangs. Something very wrongs is happening with the driver. I guess I will just sell it. For airodump works perfectly but I want to use your tool. |
|
My m76 devices are running fine. That include TP-LINK Archer T2UH as well as EDIMAX EW-7711UAN, ALLNET ALL-WA0150N and SEMPRE WU150-1. What happen if you run hcxdumptool passive (--silent)? Running this mode hcxdumptool will not transmit and we have no tx workload. Does the driver freeze? Cheers |
|
Please notice that hcxdumptool (in attack mode) produce a hundred times more workload than the whole aircrack-ng suite. The tool is working as 512 ACCESS POINTs , 1024 CLIENTs, a dumper and a deauther, simultanious. That include also all EAP authentications. Additional it will request missing packets on packet loss to calculate a valid EAPOL message pair. |
|
Also you should know that the TP-LINK TL-WN722N v1 is a very old device: FCC approval date: 18 November 2009 |
|
Last, but not least some words about aircrack-ng suite: |
Hello. Thank you for all your explanations. I can confirm that running airodump + aireplay + mdk3 does not freeze the adapter. Everything keeps working. I tried that for at least 30 minutes without problem. Instead hcxdumptool (without silent flag) freezed after 15 minutos approximately. I will try now the silent mode and leave it working for several hours. I will report back. |
|
Thanks for that information. Maybe we can find a solution. |
|
After 5 hours running in silent mode, hcxdumptool did not freeze. |
|
Great, thanks for testing it. Now we can assume that the tx queue overflow on heavy workload and the device doesn't accept packets to transmit any longer. |
|
The issue passible can be caused by hardware (overheat) as mentioned here: |
|
Yes, I think we will not resolve this mistery. At this point it's easier to change the device for another. |
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.pcapngIt 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
Everything is fine here.
The text was updated successfully, but these errors were encountered: