ath9k_htc driver problems #209
Comments
|
Please test latest commit: |
|
$ hcxdumptool -I $ sudo hcxdumptool -i wlp5s0f4u2 --check_driver driver tests passed... terminating... $ sudo hcxdumptool -i wlp5s0f4u2 --check_injection terminating... |
|
Now it's getting better. passed driver test but couldn't capture anything. So, I reboot the machine and test injection. |
|
Here is the injection result I ran after rebooting... |
|
I got another issue report on ath9k driver (closed, because it is similar to yours): Running enable_status=64 (if you want to see other messages, too, set it to 95), you'll get some more information (ERROR counter state, and state of incoming and outgoing packets. Some times the driver is working as expected (INCOMING and OUTGOING packet counter increase. But sometimes the driver doesn't respond (INCOMING:0 AGE:1 OUTGOING:0): After some investigation on bugzilla.kernel.org I noticed that there are some related issues on this driver: Like wpa_supplicant, hcxdumptool noticed that, too, as mentioned here: Now we have to figure out, why the driver is broken. BTW: |
|
Thanks for caring for this driver. |
|
Unfortunately, you are right. After after the error occurred, the driver is dead. |
|
@ZerBea This driver issue can be reverted with a kernel rollback? if it's possible how i can rollback to another ? And why it works fine on VM? |
|
Actually I don't think roll back kernal is not a solution because up before that all your programs are running smoothly and you tackled the kernal and the specific program might be working but what might happen to the rest of programs? I am not a pro but advise me. |
|
You can rollback to a version all programs worked well anyways, like on a version all programs and drivers worked well you know |
|
you need to check the best kernel version you can list those and rollback, it happens on most verswions of anything, i'll try it soon. |
|
I'm still not sure how to deal with this issue. Also I'm not sure which kernel version is affected: |
|
Ok, found another notice about this issue: |
|
@ZerBea I can say that on my vm i didn't updated or upgraded anything it works on so that's why i said we could rollback, in my case so i don't know the other case you know how i can downgrade my version of the bare metal kali from 5.16.0 to 5.15.0 ? |
|
└─$ sudo hcxdumptool -i wlan0 -o dumpfile.pcapng --active_beacon --enable_status=95 start capturing (stop with ctrl+c) TIME FREQ/CH MAC_DEST MAC_SOURCE ESSID [FRAME TYPE] Maybe it still doesn't works pretty well on vm tho.. hmm |
|
Anyways zerbea you know if it's better to downgrade or use vm instead? you know when this issue will be fixed? thanks for everything |
|
Talking about downgrade, what am I suppose to do? Mine is 5.13.0. Upgrading to 5.15 ? Let me search online how to upgrade to a specific kernel version. |
|
Finished the tests on kernel 5.10.103+ and 5.16.16 running 6 devices in parallel: driver:rtw_8821ce -> broken |
|
Also I'm not sure how the HOST handle the GUEST if running hcxdumptool in a VM. |
|
Forn me, bare metal. X86-64, Ubuntu |
|
Thanks. |
|
There are several changes from 5.16 to 5.17: Maybe one of them fixed the issue as mentioned on Arch Linux bug tracker: Additional there are two more scheduled: |
|
Just upgraded to 5.17.1 |
|
I don't think it is working, because INCOMING packet count is too less and stopped at 226 Test adapter is TP-Link TL-WN722N V1 |
|
My adapter is Atheros AR9271 Chipset 150Mbps Wireless USB WiFi Adapter 802.11n |
|
Same chipset, same firmware and same driver, so we should expect the same behavior - but unfortunately that isn't the case. |
|
device capabilities: |
|
Conclusion: @aurhack how about AWUS036NHA ? |
|
Both commands didn't work for me. How do I do that? @ZerBea |
|
OK I got the first one:- here |
|
Ok, thanks. That is identical to mine. |
|
Maybe this is the one? |
|
Thanks again. Here is something different. TL-WN722N support ACK timeout estimation: |
Let me try rn! Sorry i was studying i study on afternoons. |
|
@ZerBea how i can update my kali linux to version 5.17.1? |
|
That can't be done in an easy way, because you have to compile the Linux kernel from scratch. At the moment I'm running out of ideas. I'll do some more tests. Maybe I can find a solution. |
|
It's okay, i'll buy AWUS036AC, David Bombal said that IN his opinion it was the best adapter and at this day i think it's compatible and it'll work with the recent kernel of Kali, i'm gonna refund tomorrow the AWUS036NHA |
|
Maybe purchasing an AWUS036AC is not a good idea. Take a look at the video made by David: Also please take a look at the issue reports regarding this driver: From hcxdumptool README.md adapter section: |
|
Result of the long term test an AR9271: INCOMING and OUTGOING packet count increased |
|
Please take a look at this newer video made by David: |
|
Hey @ZerBea Here is the result with hashcat:- |
|
That and my own tests confirm a driver issue which is possible fixed by kernel 5.17.1-arch1-1 (the driver no longer crashes). |
|
Here is another interesting issue report on that driver: BTW: |
Maybe that's why it reconnects wireless network automatically |
|
But I'm still puzzled by aircrack-ng and airodump-ng working perfectly |
|
In contrast to wpa_supplicant, hcxdumptool doesn't restart a "broken" device. |
|
@ZerBea just to cross-report here too. With me bare metal was ok (24h test) and VM was not! This was replicated to Kali simply joining a wifi AP (no monitor mode or something fancy..) |
|
@varoudis , thanks for that information, which is very much appreciated. Also I'm still not sure if the issue is related to the firmware or the driver. |
|
@hklsb there is a big difference between airodump-ng and hcxdumptool. Doing this, hcxdumptool is acting as ACCESS POINT, CLIENT and DEAUTHENTICATOR at the same time. That can produce a huge workload on the driver, because 512 APs, 1024 ROGUE APs and 1024 CLIENTs can be handled simultaneously. This is the major reason, why I don't use libpcap or libnl due to their NETLINK dependency. BTW: |
|
Maybe my usb adapter is not powerful enough for hcxdumptool? |
|
No, the power of an adapter doesn't matter, but it is mandatory that the driver support full monitor mode, full packet injection and is flawless. |
|
A little bit out of ath9k_htc topic, but very interesting: |
|
Hello, Today I decided to test my TL-WN722N V1.1 for the very first time with hcxdumptool and I experienced same issue as #80. After reading that topic I was about to buy a new usb adapter, Then I noticed #209 and read all posts. Then downloaded today's daily kali iso (5.16.0-kali7-amd64) found here: https://archive.kali.org/kali-daily-images/ , intalled it to VMware. Now in this version of Kali TL-WN722N V1.1 works much longer than before (Like 40-50 min vs 5-10 min) till frezee. |
|
Thanks for this information. In most of the cases the problem is related to the driver. |
|
Closed. We have to wait for a driver fix. |
Hi I was using aircrack-ng + airodump-ng with atheros wireless adapter, successful.
But I realize hcxdumptool is modern way especially with new wpa2 thing.
So I tried but get error, anyone have this issue?
uname -r5.13.0-39-generichcxdumptool -vhcxdumptool 6.2.5-59-gf138052 (C) 2021 ZeroBeathcxdumptool -Isudo hcxdumptool -i wlxc01c300da43d --check_driverNote: I've been reading and looking for these issues for hours but couldn't find a solution.
Is my adapter not supported by hcxdumptool?
The text was updated successfully, but these errors were encountered: