ZerBea
commented
5 years ago Please add the your used command line of latest hcxdumptool. Please add output of: $ hcxdumptool -I $ hcxdumptool -i "your interface" --check-driver
Closed TenoTrash closed 5 years ago
ZerBea
commented
5 years ago Please add the your used command line of latest hcxdumptool. Please add output of: $ hcxdumptool -I $ hcxdumptool -i "your interface" --check-driver
adduty
commented
5 years ago It's hard to tell because the original post is a little vague, but I believe I am experiencing the same issue. I am using an Alfa AWUS036ACH
$ hcxdumptool --version hcxdumptool 6.0.0 (C) 2019 ZeroBeat
$ hcxdumptool -I wlan interfaces: 5800e398b347 wlan0 (ath10k_pci) 00c0ca966636 wlan1 (rtl88xxau)
$ sudo hcxdumptool -i wlan1 --check_driver initialization... starting driver test... driver tests passed... all required ioctl() system calls are supported by driver
terminating...
When I run $ sudo hcxdumptool -i wlan1 --do_rcascan=3
it takes a few seconds to see any APs, and I can let it run for a minute or so before it sees my AP, which is closer and has a stronger signal than the other APs it sees first.
If I build hcxdumtool v5.2.2, it works as expected--I see many APs immediately and my AP shows up quickly.
ZerBea
commented
5 years ago Ok, that is clear. By latest commit: https://github.com/ZerBea/hcxdumptool/commit/e5fd93f8b8170c26b39af8fd96f18fd632951004 rcascan is changed to old behaviour. We do not need a value any longer. COUNTs and HITs are shown at the same time. example: sudo hcxdumptool -i wlan1 --do_rcascan
If you got no HIT, packet injection isn't working like expected or no ACCESS POINT is in range. But it is more likely that the driver isn't working like expected. The rtl88xxau driver is known for several issues especially regarding packet injection: https://github.com/aircrack-ng/rtl8812au/issues/459 https://github.com/aircrack-ng/rtl8812au/issues/458 https://github.com/aircrack-ng/rtl8812au/issues/451 https://github.com/aircrack-ng/rtl8812au/issues/448 https://github.com/aircrack-ng/rtl8812au/issues/439 https://github.com/aircrack-ng/rtl8812au/issues/422 https://github.com/aircrack-ng/rtl8812au/issues/387 https://github.com/aircrack-ng/rtl8812au/issues/380 https://github.com/aircrack-ng/rtl8812au/issues/376 and more...
ZerBea
commented
5 years ago I'm running kernel 5.3.10 $ uname -r 5.3.10-arch1-1
and the driver crashed directly after a device (rtl8811au) is plugged in:
[ 353.534645] usb 1-2: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[ 353.534654] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 353.534659] usb 1-2: Product: Edimax AC600 USB
[ 353.534664] usb 1-2: Manufacturer: Realtek
[ 353.534669] usb 1-2: SerialNumber: 00e04c000001
[ 353.624543] rtl88xxau 1-2:1.0 wlp0s20f0u2: renamed from wlan0
[ 438.293341] device wlp0s20f0u2 entered promiscuous mode
[ 457.406728] WARNING: CPU: 1 PID: 3597 at net/mac80211/rx.c:804 ieee80211_rx_napi.cold+0xc/0x67 [mac80211]
[ 457.406729] Modules linked in: 88XXau(OE) hid_generic usbhid fuse nls_iso8859_1 nls_cp437 vfat fat nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) snd_soc_skl snd_soc_hdac_hda uvcvideo snd_hda_ext_core snd_soc_skl_ipc videobuf2_vmalloc snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core videobuf2_memops videobuf2_v4l2 snd_hda_codec_hdmi snd_compress x86_pkg_temp_thermal ac97_bus videobuf2_common intel_powerclamp snd_pcm_dmaengine rtl8821ae videodev coretemp rtsx_usb_ms mc snd_hda_codec_realtek btcoexist snd_hda_codec_generic kvm_intel rtl_pci memstick ledtrig_audio kvm rtlwifi snd_hda_intel joydev snd_hda_codec mac80211 btusb mousedev irqbypass btrtl r8169 intel_rapl_msr btbcm btintel snd_hda_core bluetooth i915 cfg80211 snd_hwdep snd_pcm crct10dif_pclmul ipmi_devintf crc32_pclmul asus_nb_wmi ipmi_msghandler ghash_clmulni_intel libarc4 aesni_intel snd_timer realtek aes_x86_64 crypto_simd cryptd glue_helper i2c_hid i2c_algo_bit intel_cstate mei_hdcp
[ 457.406764] intel_uncore hid libphy snd asus_wmi ecdh_generic intel_rapl_perf ecc sparse_keymap iTCO_wdt iTCO_vendor_support drm_kms_helper rfkill drm soundcore pcspkr mxm_wmi tpm_crb processor_thermal_device elan_i2c tpm_tis input_leds intel_gtt tpm_tis_core intel_rapl_common int3403_thermal tpm agpgart int340x_thermal_zone syscopyarea sysfillrect sysimgblt fb_sys_fops intel_xhci_usb_role_switch roles intel_soc_dts_iosf evdev mei_me mei mac_hid idma64 rng_core intel_lpss_pci intel_lpss i2c_i801 int3400_thermal acpi_thermal_rel intel_pch_thermal wmi asus_wireless ac battery sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 rtsx_usb_sdmmc mmc_core rtsx_usb sr_mod cdrom sd_mod serio_raw atkbd libps2 ahci libahci libata xhci_pci crc32c_intel scsi_mod xhci_hcd i8042 serio
[ 457.406799] CPU: 1 PID: 3597 Comm: NetworkManager Tainted: P W OE 5.3.8-arch1-1 #1
[ 457.406800] Hardware name: ASUSTeK COMPUTER INC. X555UB/X555UB, BIOS X555UB.301 02/20/2017
[ 457.406820] RIP: 0010:ieee80211_rx_napi.cold+0xc/0x67 [mac80211]
[ 457.406822] Code: 38 48 81 c1 70 04 00 00 48 81 c6 38 01 00 00 e8 0a 20 74 ce b8 01 00 00 00 e9 26 4b fb ff 48 c7 c7 60 9b ce c0 e8 b7 33 22 ce <0f> 0b 48 89 ef e8 7f 08 87 ce e9 d1 5b fb ff 48 c7 c7 60 9b ce c0
[ 457.406822] RSP: 0018:ffffabe380120e10 EFLAGS: 00010246
[ 457.406823] RAX: 0000000000000024 RBX: ffff93062f2a07a0 RCX: 0000000000000000
[ 457.406824] RDX: 0000000000000000 RSI: ffff93063ba97708 RDI: 00000000ffffffff
[ 457.406825] RBP: ffff93062dcd0400 R08: 000000000000078a R09: 0000000000000001
[ 457.406825] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[ 457.406826] R13: 0000000000000001 R14: 0000000000000006 R15: 0000000000000000
[ 457.406827] FS: 00007f096654bd80(0000) GS:ffff93063ba80000(0000) knlGS:0000000000000000
[ 457.406828] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 457.406828] CR2: 00007f80080ce198 CR3: 000000022d662003 CR4: 00000000003606e0
[ 457.406829] Call Trace:
[ 457.406832]
Do you see similar crashes in your dmesg log?
adduty
commented
5 years ago I do not see that, but I am running on Kali: $ uname -r 5.2.0-kali2-amd64
adduty
commented
5 years ago Unfortunately, however, I am still experiencing the same behavior with do_rcascan after building from latest commit (https://github.com/ZerBea/hcxdumptool/commit/3d2fba2c53ea5279890d0bf4740ff70472f402f8).
ZerBea
commented
5 years ago I'm not able to get this driver to work. Neither running hcxdumptool: $ iw dev phy#4 Interface wlp0s20f0u3 ifindex 7 wdev 0x400000001 addr d2:b1:51:45:c7:ec type monitor channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz txpower 18.00 dBm
$ hcxdumptool -I 74da380645e7 wlp0s20f0u3 (rtl88xxau)
$ hcxdumptool -i --do_rcascan BSSID CH COUNT HIT ESSID [17:00:07] terminating...
nor running airodump-ng:
$ airodump-ng wlp0s20f0u3
CH 9 ][ Elapsed: 0 s ][ 2019-11-12 17:09
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
BSSID STATION PWR Rate Lost Frames Probe
while this drivers working excellent: $ hcxdumptool -I wlan interfaces: 74da38f2038f wlp3s0f0u2 (mt7601u) c83a35cb08e3 wlp3s0f0u1 (rt2800usb) 503eaaa08f6f wlp3s0f0u2 (mt76x0u) f81a67077d0e wlp3s0f0u2 (ath9k_htc)
the realtek drivers are a nightmare.
ZerBea
commented
5 years ago ...and it looks like the ath10k_pci driver is running into a firmware issue: https://bugzilla.kernel.org/show_bug.cgi?id=205311
A google search on "ath10k_pci issue" will confirm this, too.
As well as the issues on rtl88xxau: https://github.com/v1s1t0r1sh3r3/airgeddon/issues/259 https://community.parrotlinux.org/t/realtek-rtl8812au-driver-alfa-awus036ach/206
you can try to set monitor mode running iw: $ ip link set wlan1 down $ iw dev wlan1 set type monitor $ ip link set wlan1 up
But I'm sure it doesn't work, because iw use netlink (libnl)to create the interface and hcxdumptool will not work on pure netlink interfaces.
ZerBea
commented
5 years ago Let me explain my policy in a few words: First of all I'm coding and testing against the official Linux kernel: https://www.kernel.org/ If I encounter an issue, I'm going to report it there: 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=202541 https://bugzilla.kernel.org/show_bug.cgi?id=205305
Next step is to report distribution related issues to my favorite distribution https://www.archlinux.org/ https://bugs.archlinux.org/task/60165
Your driver rtl88xxau isn't part of the official Linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/realtek?h=v5.3.11 The official driver doesn't support monitor mode and packet injection. So I'm not able to reproduce it. But I'm in contact with Christian [https://github.com/kimocoder]. He is working hard to fix tons of issues regarding this drivers https://github.com/aircrack-ng/rtl8812au https://github.com/aircrack-ng/rtl8188eus Unfortunately he is very busy and has not so much time to work on the driver.
kimocoder
commented
5 years ago frame injection for 88XXau got issues. This will be priority right away!
ZerBea
commented
5 years ago @kimocoder Realtek drivers are a nightmare and the (my) only ray of hope is your excellent work on this drivers. It looks like the Linux kernel release cycle is a little bit too high for Realtek software engineers (I noticed that on AMD, too) and they cannot keep up. I took a closer look at the driver code. Unfortunately it is not easy to understand what is going on inside. For me it looks like the original code is composed of several different versions - regardless if it works or not. But the devices are cheap and not so bad for their price. So having a full functional driver will be a big improvement. My early tests on both drivers showing big potential (especially the 8188eus running in combination with a TP-LINK-WN722 v2)
kimocoder
commented
5 years ago I have a brand new Realtek release of the rtl8188eus btw! But I don't have time to update that quite yet.. It will have to wait
ZerBea
commented
5 years ago That sounds good.
BTW: For a short time, I was able to get the rtl8188eu working and the results were very, very good: https://github.com/ZerBea/hcxdumptool/issues/48#issuecomment-471207243
ZerBea
commented
5 years ago @adduty and we need full working packet injection, because we transmit proberequests https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L3563 and count the responds https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L3340
ZerBea
commented
5 years ago @adduty I think we can close this issue, because the driver issue in KALI is confirmed: https://github.com/aircrack-ng/rtl8812au/issues/469
kimocoder
commented
5 years ago It's working now 😅
kimocoder
commented
5 years ago 
hcxdumptool also
ZerBea
commented
5 years ago amazing!
ZerBea
commented
5 years ago By latest commit https://github.com/ZerBea/hcxdumptool/commit/148b11d35a5fdcdc77bface48e94397658c6d899 scan speed is increased by 50%. Now we do not spend so much time on an empty channel. https://github.com/ZerBea/hcxdumptool/commit/148b11d35a5fdcdc77bface48e94397658c6d899#diff-56f0554ece9939c694f65b93a8468553R3256 Is it still working with the driver? It works fine on rt2800usb, mt76 and ath9k_htc and I assume, it will work on 8812au and rtl8188eus (and of course wifite2), too
kimocoder
commented
5 years ago Yes it works, have to spend some days with some other miners like regdom (unlocking all channels) and scanning/fixes in general. Just glad to have the basics up and running
ZerBea
commented
5 years ago Good to hear that. Thanks. I have to play around with this values. My be we can speed up them. These are the last measured values between EAPOL messages: MP:M1M2 RC:12 EAPOLTIME:4369 MP:M2M3 RC:13 EAPOLTIME:12673 MP:M1M2 RC:1 EAPOLTIME:3379 MP:M2M3 RC:2 EAPOLTIME:3773 MP:M1M2 RC:1 EAPOLTIME:2952 MP:M2M3 RC:2 EAPOLTIME:12956 MP:M1M2 RC:1 EAPOLTIME:6299 MP:M2M3 RC:2 EAPOLTIME:13582
We stay 500000 microseconds on an empty channel - that is more than enough, if we take a look at the real EAPOL times.
kimocoder
commented
5 years ago root@kimocoder:~/Downloads# hcxdumptool -i wlan1
initialization...
interface is already in monitor mode
start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE......:
INTERFACE NAME..........: wlan1
INTERFACE HARDWARE MAC..: 00c0caa47b06
DRIVER..................: 88XXau
DRIVER VERSION..........:
DRIVER FIRMWARE VERSION.:
ERRORMAX................: 100 errors
FILTERLIST ACCESS POINT.: 0 entries
FILTERLIST CLIENT.......: 0 entries
FILTERMODE..............: 0
WEAK CANDIDATE..........: 12345678
PREDEFINED ACCESS POINT.: 0 entries
MAC ACCESS POINT........: 000e22781df9 (incremented on every new client)
MAC CLIENT..............: c02250f7edd1
REPLAYCOUNT.............: 62706
ANONCE..................: 230fbfbeebbe0eb08f914a3884dc914fddfbdc062495b537d2689d44a75e6c6e
SNONCE..................: 12c6fd6869cb70858d24d42686bccbb45f9dbac84532c5c4c81ea0a1a039ae4aGood. As long as we do not reach the 100 errors and as long as we will get some hits (hcxdumptool -i interface --do_rcascan) everything is fine with the driver. Now I'm refactoring hcxpcaptool to v 6.0.0
Increased level of aggressiveness again. We do not stop after the first attempt of a client to connect to us. Now we allow every attempt. That is necessary in case of the client typed a false PSK on the first attempt.
Hello there!
I just formatted my laptop, and git clone the new version of hcxdumptool.
After installing, cannot get any good captures.
Having around version hcxdumptool 5.1.0, replace and now it works!
Using Alfa USB adapter.
Cheers!