Rtl8812au: Injection not working in monitor mode

[marc-y-marc]

I'd like to re-open this issue:

https://github.com/aircrack-ng/rtl8812au/issues/348

I have the same identical problem. When monitor mode is set, injection is not working anymore.

kernel: 4.15.0-1037-raspi2

[marc-y-marc]

Small correction: it does work with ifconfig & iwconfig.

It does not work with ip link and iw dev.

[marc-y-marc]

Ok all, i found out what the problem was. Please also see this issue: https://github.com/secdev/scapy/issues/2076

There seems to be an issue with the 5.3.4 branch (and up) of the driver.

when libpcap needs to PCAP_SET_RFMON to 1 it just doenst PCAP_ACTIVATE() anymore and results in error code -1.

I went back to the 5.2.20 driver and everything worked again! Not sure if related but i did not use the dkms installer. I also used ifconfig and iwconfig instead of ip link and iw dev (which is in the manual).

[kimocoder]

@marc-y-marc We know. Take a look here https://github.com/t6x/reaver-wps-fork-t6x/issues/282

But for me it is different, on v5.3.4 i have to use "iw" and "ip" (and not the ongoing deprecationed ifconfig/iwconfig), anyhow the v5.6.4 is quite more stable than the v5.3.4 again (but it only got support for 8812au still) as I could need some help adding phydm and HAL for 8821au and 8814au from @fariouche when he's available :+1:

[kimocoder]

v5.3.4 got some stability issues I noticed early on, I have to put the device up & down and do a scan in between (before I put it in monitor mode, then I'll do a scan more) then I test injection.

[marc-y-marc]

I also reverted to the 5.2.20 branch and all was OK. I'm ok to close this issue since we will move on to the 5.6.4 branch - when people search regarding this issue at least they know how to resolve it :-)

[kimocoder]

True. We'll try to move forward soon hopefully

[FrankSpierings]

Switching back to driver version 5.2.20 fixed the issue I had with bettercap as well: error while activating handle: unknown activated error: -1. https://github.com/bettercap/bettercap/issues/232.

Kernel: Linux raspberrypi 4.19.50-v7+ #896 SMP Thu Jun 20 16:11:44 BST 2019 armv7l GNU/Linux
Device: 0bda:8813 Realtek Semiconductor Corp. RTL8814AU 802.11a/b/g/n/ac Wireless Adapter

[ZerBea]

I can confirm that, too. Last working version is 5.2.20

v5.3.4:
[ 1587.160352] usb 1-1: new high-speed USB device number 16 using xhci_hcd
[ 1587.300528] usb 1-1: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[ 1587.300538] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1587.300544] usb 1-1: Product: Edimax AC600 USB
[ 1587.300549] usb 1-1: Manufacturer: Realtek
[ 1587.300553] usb 1-1: SerialNumber: 00e04c000001
[ 1587.388469] rtl88xxau 1-1:1.0 wlp0s20f0u1: renamed from wlan0
[ 1627.745603] device wlp0s20f0u1 entered promiscuous mode

$ uname -r
5.2.8-arch1-1-ARCH

$ sudo ./aireplay-ng --test wlp0s20f0u1
15:32:14 Trying broadcast probe requests...
15:32:16 No Answer...

$ sudo hcxdumptool -i wlp0s20f0u1 --do_rcascan
INFO: cha=10, rx=777, rx(dropped)=0, tx=89, err=0, aps=12 (0 in range, WARNING: packet injection possible not working)

[kimocoder]

v5.2.20(.2) is the most stable atm, v5.3.4 was never finished as a new release followed shortly after release. Will start tomorrow getting the v5.6.4.1 up & running

[ZerBea]

@kimocoder , thanks for the info, Christian. v5.2.20 is running fine here, after I reverted that nasty xhci patch (https://bugzilla.kernel.org/show_bug.cgi?id=202541).

v5.6.4.1 showing some issues. It looks like some ioctl() system calls are not supported, yet and I hope, that you're able to fix it. hcxdumptool neither use libpcap nor libnl, because I can't run all attack modes using libpcap and/or libnl (unfortunately iw creates sometimes netlink monitor interfaces - airmon-ng internally runs iw - and that is the reason why hcxdumptool print a warning if it detect a monx interface).

v.5.6.4.1
[ 475.980056] RTW: module init start
[ 475.980058] RTW: rtl88xxau v5.6.4.1_33916.20190619
[ 475.980058] RTW: build time: Aug 13 2019 16:30:29
[ 475.980068] RTW: rtw_inetaddr_notifier_register
[ 475.980096] usbcore: registered new interface driver rtl88xxau
[ 475.980096] RTW: module init ret=0
[ 479.425800] usb 1-1: new high-speed USB device number 6 using xhci_hcd
[ 479.566587] usb 1-1: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[ 479.566597] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 479.566603] usb 1-1: Product: Edimax AC600 USB
[ 479.566608] usb 1-1: Manufacturer: Realtek
[ 479.566612] usb 1-1: SerialNumber: 00e04c000001

$ sudo hcxdumptool -i wlp0s20f0u1 --check_driver
ioctl(SIOCGIFFLAGS) - IFF_UP | IFF_RUNNING | IFF_BROADCAST failed
it looks like this interface/driver isn't suitable for hcxdumptool

$ sudo iw dev wlp0s20f0u1 set type monitor
command failed: Operation not permitted (-1)

[ZerBea]

latest v5.6.4.1 (head: 9daa7978e941b7304e42a08d5884031c9b998673) showing some issues on ioctl() system calls:
v5.6.4.1
$ sudo hcxdumptool -i wlp0s20f0u3 --check_driver
ioctl(SIOCSIWMODE) - IW_MODE_MONITOR failed: Operation not permitted
ioctl(SIOCGIWMODE) - IW_MODE_MONITOR failed
ioctl(SIOCGIFFLAGS) - IFF_UP | IFF_RUNNING | IFF_BROADCAST failed

$ sudo hcxdumptool -i wlp0s20f0u3 --do_rcascan
initialization...
NFO: cha=1, rx=0, rx(dropped)=0, tx=21, err=0, aps=0 (0 in range, WARNING: packet injection possible not working)

compared to latest v5.2.20 (head: 32aad896942226a84bb19538d73f950ddc7a6d49):
v5.2.20
$ sudo hcxdumptool -i wlp0s20f0u3 --check_driver
driver tests passed - all required ioctl() system calls are supported by driver

$ sudo hcxdumptool -i wlp0s20f0u3 --do_rcascan
initialization...
INFO: cha=1, rx=131, rx(dropped)=0, tx=19, err=0, aps=8 (6 in range)

[kimocoder]

Yeah I barely started looking into the driver.. also ran cppcheck to it, and boy it was lots..

[ZerBea]

I didn't run tests with airodump-ng, aireplay-ng and airmon-ng, but I'm sure they will show something similar.

BTW:
iw is able to put the interface into monitor mode:
Interface wlp0s20f0u3
ifindex 5
wdev 0x200000001
addr 74:da:38:06:45:e7
type monitor
wiphy 2
txpower 0.00 dBm

Unfortunately this monitor mode will not work. That also has an impact on airmon-ng, because the script runs iw to activate monitor mode.

[kimocoder]

But I use it on a daily basis, and it works like a charm.. don't get it.. but I'll go deep to find it

[kimocoder]

[ZerBea]

That is very interesting. Just compiled aircrack-ng suite and got similar issues:
$ uname -r
5.2.8-arch1-1-ARCH

$ sudo iw dev wlp0s20f0u3 info
interface wlp0s20f0u3
ifindex 7
wdev 0x400000001
addr 74:da:38:06:45:e7
type monitor
wiphy 4
txpower 0.00 dBm

$ sudo ./wash -i wlp0s20f0u3
BSSID Ch dBm WPS Lck Vendor ESSID
empty scan list

$ sudo ./airodump-ng wlp0s20f0u3
ioctl(SIOCSIWMODE) failed: Operation not permitted
ioctl(SIOCSIWMODE) failed: Operation not permitted
Error setting monitor mode on wlp0s20f0u3
Failed initializing wireless card(s): wlp0s20f0u3

Also I noticed a possible issue during init and/or de-init. Depending on the tool which used the driver I got different start values after I removed/plugged-in the device several times.

Which kernel do you run?

[ZerBea]

Just installed a fresh Linux system inclusive aircrack-ng suite and LTS kernel 4.19 and v5.6.4.1 (head: d664d7e9494938a4610b3ce664919dcd0100e1c2)
Running only aircrack-ng tools (and iw) to make sure the issue isn't related to hcxdumptool

$ sudo airmon-ng start wlp0s29f7u1
PHY Interface Driver Chipset
phy5 wlp0s29f7u1 88XXau Edimax Technology Co., Ltd
(monitor mode enabled)
Error setting channel: command failed: Device or resource busy (-16)
Error -16 likely means your card was set back to station mode by something.
Removing non-monitor wlp0s29f7u1 interface...

At this point we use iw to enable monitor mode:
$ sudo ip link set wlp0s29f7u1 down
$ sudo iw dev wlp0s29f7u1 set type monitor
$ sudo ip link set wlp0s29f7u1 up
$ sudo iw dev wlp0s29f7u1 info
Interface wlp0s29f7u1
ifindex 8
wdev 0x500000001
addr 74:da:38:06:45:e7
type monitor
wiphy 5
txpower 0.00 dBm

and run airmon-ng again:
$ sudo airmon-ng start wlp0s29f7u1
PHY Interface Driver Chipset
phy5 wlp0s29f7u1 88XXau Edimax Technology Co., Ltd
(mac80211 monitor mode already enabled for [phy5]wlp0s29f7u1 on [phy5]10)

Now everything is looking fine, but running airodump-ng results in an empty scan list
$ sudo airodump-ng wlp0s29f7u1

[kimocoder]

Latest branch, right? It has been working all along over here.. i don't get it? comparison to all my other cards.. the 8812au has become powerfull after v5.6.4 (new phydm, txpower issues resolved).

It beast the crap out of whole my collection with WiFi equipment. But I'm looking into IOCTL in the code now, have pushed alot. Right now I'm focusing on all this shit hardcoded styff, and nuking old & unused.

Will go back to more bug related stuff shortly :+1:

[ZerBea]

Yes, the new rtw88 driver is really good. I'll do some more tests (on latest git head) and take a closer look into the driver code.
Right now, we know it isn't related to the kernel version (but I'll test some other kernel configs) and it isn't related to iw, airodump-ng or hcxdumptool. Maybe it's related to the Edimax AC600 device, itself.
I really wonder why iw (5.3) is able to put the device into monitor mode while all other tools (airmon-ng, hcxdumptool) failed. Maybe, I have to take a look into netlink code, too.

BTW:
I'm running 4 systems here. All of them showing the same issue (v5.2.20 working, v5.6.4.1 not):
RYZEN 1700, MSI X370 KRAIT
INTEL i7-3930K, ASUS P9X79
INTEL I5-6200U, ASUS X555U (notebook)
INTEL N270, Medion Akoya E1210 (kernel 4.19.59-LTS)

In any case, your work on that driver is really, really awesome!

[kimocoder]

I got some issue patches awaiting, plugged a kfree buffer in kernel v4.19 earlier.
Got more coming :1st_place_medal:

[kimocoder]

Found a couple IOCTL problems, plug'em as I go ..

https://github.com/aircrack-ng/rtl8812au/commit/8f04e62ca7fc50a0d01f012dd1ae7b4fda5f6b91

[ZerBea]

Tested latest head c2fd51ad82af369529c9c3960f7d56c6f949793a and noticed some changes:
First run:
$ sudo hcxdumptool -i wlp0s20f0u3 --check_driver
ioctl(SIOCSIWMODE) - IW_MODE_MONITOR failed: Operation not permitted
ioctl(SIOCGIWMODE) - IW_MODE_MONITOR failed
ioctl(SIOCGIFFLAGS) - IFF_UP | IFF_RUNNING | IFF_BROADCAST failed

Second run, without removing the device between the runs:
$ sudo hcxdumptool -i wlp0s20f0u3 --check_driver
driver tests passed - all required ioctl() system calls are supported by driver

Then the driver crashed the USB host:
[ 1020.834976] RTW: module init start
[ 1020.834977] RTW: rtl88xxau v5.6.4.1_33916.20190619
[ 1020.834982] RTW: rtw_inetaddr_notifier_register
[ 1020.835010] usbcore: registered new interface driver rtl88xxau
[ 1020.835011] RTW: module init ret=0
[ 1025.093502] usb 1-3: new full-speed USB device number 28 using xhci_hcd
[ 1025.216851] usb 1-3: device descriptor read/64, error -71
[ 1025.446855] usb 1-3: device descriptor read/64, error -71
[ 1025.676820] usb 1-3: new full-speed USB device number 29 using xhci_hcd
[ 1025.800178] usb 1-3: device descriptor read/64, error -71
[ 1026.030203] usb 1-3: device descriptor read/64, error -71
[ 1026.136902] usb usb1-port3: attempt power cycle
[ 1026.780147] usb 1-3: new full-speed USB device number 30 using xhci_hcd
[ 1026.780341] usb 1-3: Device not responding to setup address.
[ 1026.987033] usb 1-3: Device not responding to setup address.
[ 1027.193466] usb 1-3: device not accepting address 30, error -71
[ 1027.316803] usb 1-3: new full-speed USB device number 31 using xhci_hcd
[ 1027.317027] usb 1-3: Device not responding to setup address.
[ 1027.523639] usb 1-3: Device not responding to setup address.
[ 1027.730137] usb 1-3: device not accepting address 31, error -71
[ 1027.730324] usb usb1-port3: unable to enumerate USB device

dmesg doesn't show this warning:
WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state
so, I assume the issue isn't related to this xhci bug
https://bugzilla.kernel.org/show_bug.cgi?id=202541

I removed the USB 3 commit (head: 7ff8e97218508ee7a3064b40c5d7a0a2e88343ac)
and that possible fixed the USB host crash:
[ 250.019495] usbcore: registered new interface driver rtl88xxau
[ 250.019496] RTW: module init ret=0
[ 256.193515] usb 1-3: new high-speed USB device number 15 using xhci_hcd
[ 256.334204] usb 1-3: New USB device found, idVendor=7392, idProduct=a812, bcdDevice= 2.00
[ 256.334213] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 256.334219] usb 1-3: Product: Edimax AC600 USB
[ 256.334224] usb 1-3: Manufacturer: Realtek
[ 256.334229] usb 1-3: SerialNumber: 00e04c000001
[ 256.337207] RTW:
usb_endpoint_descriptor(0):
[ 256.337213] RTW: bLength=7
[ 256.337216] RTW: bDescriptorType=5
[ 256.337220] RTW: bEndpointAddress=84
[ 256.337224] RTW: wMaxPacketSize=512
[ 256.337228] RTW: bInterval=0
[ 256.337231] RTW: RT_usb_endpoint_is_bulk_in = 4
[ 256.337234] RTW:
usb_endpoint_descriptor(1):

I'm not sure, what happened exactly until I do a deeper code walk through os_intfs.c

Cheers
Mike

[ZerBea]

One of the latest commits v5.6.4.1 broke compiling on
$ uname -r
5.2.8-arch1-1-ARCH

this are the last errors:
/home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.c:5363:54: error: invalid application of ‘sizeof’ to incomplete type ‘struct session_tracker’
5363 | st = (struct session_tracker )rtw_zmalloc(sizeof(struct session_tracker));
| ^~
/home/zerobeat/temp/rtl8812au_aircrack-ng/include/osdep_service.h:264:41: note: in definition of macro ‘rtw_zmalloc’
264 | #define rtw_zmalloc(sz) _rtw_zmalloc((sz))
| ^~
/home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.c:5372:17: error: ‘ST_STATUS_CHECK’ undeclared (first use in this function); did you mean ‘RT_STATUS_SUCCESS’?
5372 | st->status = ST_STATUS_CHECK;
| ^~~~~
| RT_STATUS_SUCCESS
/home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.c: In function ‘rtw_drvextra_cmd_hdl’:
/home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.c:5560:37: error: passing argument 2 of ‘session_tracker_cmd_hdl’ from incompatible pointer type [-Werror=incompatible-pointer-types]
5560 | session_tracker_cmd_hdl(padapter, (struct st_cmd_parm *)pdrvextra_cmd->pbuf);
| ^~~~~~~~~
| |
| struct st_cmd_parm *
/home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.c:5286:69: note: expected ‘struct st_cmd_parm *’ but argument is of type ‘struct st_cmd_parm *’
5286 | void session_tracker_cmd_hdl(_adapter *adapter, struct st_cmd_parm *parm)
| ~~~~^~
/home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.c: In function ‘rtw_setassocsta_cmdrsp_callback’:
/home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.c:5782:6: error: ‘struct sta_info’ has no member named ‘cmn’
5782 | psta->cmn.aid = psta->cmn.mac_id = passocsta_rsp->cam_id;
| ^~
/home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.c:5782:22: error: ‘struct sta_info’ has no member named ‘cmn’
5782 | psta->cmn.aid = psta->cmn.mac_id = passocsta_rsp->cam_id;
cc1: some warnings being treated as errors
make[2]: [scripts/Makefile.build:279: /home/zerobeat/temp/rtl8812au_aircrack-ng/core/rtw_cmd.o] Error 1
make[1]: [Makefile:1597: _module_/home/zerobeat/temp/rtl8812au_aircrack-ng] Error 2
make[1]: Leaving directory '/usr/lib/modules/5.2.8-arch1-1-ARCH/build'
make: ** [Makefile:2302: modules] Error 2

[kimocoder]

Yes I'm aware of it, didn't simply have time to correct it yesterday 😏 will have a closer look today

[kimocoder]

what device/chipset do you use @ZerBea ?

[ZerBea]

EDIMAX AC600: EW-7811UAC (RTL8811AU)
ID 7392:a812 Edimax Technology Co., Ltd

[ZerBea]

I think (but I'm not sure) the ioctl() issues are related to USB host. xhci on latest kernels is very, very instable.

[kimocoder]

Aaaah that explains alot.. the HAL was just added. 8812au is the one who's working really good.

The 8811 chipset uses 8821au, and both that and 8814au uses an old HAL (from v5.1.5) and will never be as good as 8812au has until realtek releases newer HAL's unfortunately😏 adding support for them also gives us other problems, like using the drivers on Android.. 8812au HAL supports Android 8/9, but 8814au and 8821au does not.. and the code from those older base is really, really dirty

[kimocoder]

I'll finish up the main "driver" before I start on those other chipsets and we'll see what to do

[ZerBea]

Oh, damned, I wasted your time.... Please forgive me, I didn't saw that.
But finally, we found/fixed and USB host issue.

BTW:
For what I saw, the rtl8812au driver is really good - still some overhead inside (old code), but good!

[kimocoder]

No you dont, I appreciate you taking your time to involve yourself.

Notes from "ulli-kroll":

"Realtek aka the chipdesigner does some stupid idea to switch into USB3 mode via special efuse read/write.
And this check is changed compare to the rtl8821au/rtl8814au devices
Will check for this and enable USB3"

When I'm home in couple of hours I'll add debug to all code related to USB in the driver and we'll be able to see more what's happening :+1:

[ZerBea]

We have some good drivers rt2800usb, mt76, ath9k_htc and rtl8812au. All of them allow monitor mode and full packet injection (and some ot them 5GHz, too). So it's really worth to do some work on them.

[kimocoder]

Agreed :+1: I actually got all them mentioned..and many, many more.

I also added frame injection to the new rtl8188eus (which supports LOTS of chipsets) found at https://github.com/aircrack-ng/rtl8188eus/tree/v5.7.6

Haven't made the driver known yet, published. But I bet people will like that one too,
it's a really good Realtek base :)

[ZerBea]

Yes, correct, I had to add some code to let hcxdumptool work with the driver:
https://github.com/ZerBea/hcxdumptool/issues/48#issuecomment-471204580
Maybe it's time for me to buy such a device...

BTW:
Normally I don't support third party drivers (there are too much outside in the wildness), except of both aircrack-ng drivers. Both of them rtl8812au and rtl8188eus have great potential for penetration testing applications.

[kimocoder]

Awesome, we did the same in both airmon-ng and wifite2. It's more work since it doesn't support mac80211's abilities for VIF (support) aka virtual interfaces.

Just pushed USB debug option, "CONFIG_USB_DEBUG" in Makefile.
And fixed compiling issues from yesterday.

Today I got 'em good stuff coming :1st_place_medal:

Thanks alot @ZerBea 😘

[ZerBea]

Unfortunately many users don't understand the difference between aircrack-suite and hcxdumptool/hcxtools (we have different goals).
For example:
While aircrack-ng require virtual interfaces (to let airodump-ng work in combination with aireplay-ng), hcxdumptool doesn't "like" that.
hcxdumptool is running some attack vectors within an authenticationsequence (EAP and EAPOL) between client and access point. Therefore it must be fast (and we need a fast driver here, too - we can't share the interface). Running this attack vectors hcxdumptool acts like hostapd for all(!) clients in range and wpa-supplicant for all access points(!) in range at the same time.

BTW:
I really like aircrack-ng suite. It's a very good tool set and a user can lern much basic stuff here.
wep is really great performed by the tools - but wpa need some improvements.

[kimocoder]

Really admire your work, made wifite better with more attacks too. awesome.

Well, feel free to discuss your opinions about wpa needing improvements, or Even better, feel free to tag along and push some PR's to it :+1:

I'm sure @aircrack-ng would appreciate some help :1st_place_medal:

Have a nice day, ZerBea, I'll go figure out some code again, and I'll notify you when I'll start with 8821au and 8814au testing/fixing.

[ZerBea]

Great, thanks.
Have a nice day, too.

Cheers
Mike

[PixlEmly]

Recently went through all this with an Alfa AWUS1900 - trying various drivers (including an 8814 patched 5.6.4?) Would it be worth the time for me to compile which ones did/did not work? Still haven't got hxcdumptool injecting on any of them but I think prebuilt kail on a VM on OSX isn't the best environment after all.

[ZerBea]

In your case there are many factors that influence it:
wlan dongle and its firmware (Alfa AWUS1900)
operating system and its configuration, running the VM (OSX)
VM and its configuration
wlan driver (monitor mode and full packet injection capabilities) of the operating system running within the VM (KALI)
configuration of the operating system running within the VM (KALI)
dump/attack tool (aireplay-ng, besside-ng, bettercap, hcxdumptool)

If one step failed within the ranking, the whole attack will fail.

[PixlEmly]

Appears virtualization, the rtl88xx drivers and/or hcx* aren't happy together. (although Ralink+Atheros USB devices work fine on the mac vm)

Tested more VMs in virtualbox+vmware on a few other computers (various OS), no luck, but on a real machine as soon as hcxdumptool started it immediately chewed through all the APs around.
Worked with 5.2.20, 5.3.4, 5.6.4 with the 8814 patch.

aircrack also had no issues with the VM or any driver version, but I see from here+other threads hcx* is doing things a bit differently - this is just to say the environment isn't completely broken.

Any info I could provide that might help get this sort of setup to work reliably? I can't be the only one trying it.

[ZerBea]

@PixlEmly you're absolutely right - hcxdumptool is doing thing differently (client oriented). aircrack-ng suite is more common, easier to use and working on several OS / hardware combinations. Breaking a single network, aircrack-ng is a very good choice. Breaking wep, aircrack-ng is the best choice - a reason for me not(!) to implement wep.

But that isn't the goal of hcxdumptool/hcxtools. Target is breaking the complete system without having to compromise. (12 Euro Raspberry Pi, 3 Euro Raspberry Pi case, 4.95 Euro [1] or 12,95 Euro WiFi USB dongle [2] [max 100mW], 2 x 0.05 Euro pull down resistor, 0.10 Euro LED, 15 cm wire and pure Linux Arch Operation system - no additional services installed, activated):
1: https://github.com/ZerBea/hcxdumptool/wiki/Penetration-testing-system-1
2: https://github.com/ZerBea/hcxdumptool/wiki/Penetration-testing-system-2

If you are familiar with Linux (and I don't mean installing UBUNTU using a graphical installer) and familiar with SIGINT and cryptography basic principles, hcxdumptool/hcxtools can do magic.

To determine how many compromises aircrack-ng makes to be compatible to many environments, compare the status output of the compiling process (aircrack-ng: autoreconf -i, ./configure, make - hcxdumptool: make).

@kimocoder doing a very good job on rtl8812au and 8188eus driver. rtl8812au v5.2.20 is running out of the box on an Edimax AC600 8811 device in combination with hcxdumptool (kernel 4.19, 5.2.9). Unfortunately I'm still running into some ioctl() call issues on rtl8188eus v5.7.6. It looks like this driver handles some calls in a different way.

BTW 1:
I'm running Arch Linux on main desktop, too (in combination with a 1080 TI) and have absolutely no problems running hashcat and JtR.

BTW 2:
I shared my knowledge and raw examples (PMKID attack vector, AP-LESS attack vector) with aircrack-ng team and bettercap team and I really wish they are able to add it.
https://github.com/bettercap/bettercap/issues/592#issuecomment-523501896

BTW 3:
I'm sharing knowledge with hashcat and JtR, too. For example:
I'm running JtR OpenCL kernel (and it's not stolen!):
https://github.com/ZerBea/hcxkeys/blob/master/wlangenpmkocl.c

[PixlEmly]

Running kali/arch directly + 88xxau/awus1900/hcxdumptools combo works great on the mac. missing the convenience of VM but I can live with this - not sure where it's breaking down but I last touched linux around slackware/2.6 days so I wouldn't know where to start :p

[kimocoder]

Let me inform you that the 8814au HAL is very old and very bad designed.
We need to drop future support for ut, as it breaks support for Android and lots of other stuff for 8812/8821 if the HAL doesn't get any updates soon.

Don't know yet, haven't made that decision.. but making the 8814au fit is lot of work too, as it's som far behind.

[PixlEmly]

sounds like this one's a bit of a turkey then. maybe rtw88 could one day support 8814's but for linux, sounds like I'm better off with an 8812, awus0365ach and similar. I notice a bunch of issues on these also opened but also sounds like 5.6.4 solved most of those?

[kimocoder]

Yeah me too, the rtw88 is mac80211 too, even though it's unlikely. Yeah, the issue reports i need to strip down, or need to go through 'em

[PixlEmly]

So the 036ACH arrived and.... behaves just like the AWUS1900 (at least from a user-side perspective)

Everything generally works across the different branches to varying degrees with the exception that hcxdumptools combined with this driver is not happy in a virtual machine (except on realtek-rtl88xxau-dkms [currently v5.2.20], where it sorta works some of the time?)

hcxdumptools DOES work fine in a VM with a random assortment of other USB wifi sticks I used

NO: VM + rtl8812au + hcxdumptools
Yes: VM + rtl8812au + aircrack, others
Yes: VM + (ralink, atheros 802.11n devices) + hcxdumptools
Yes: rtl8812au + hcxdumptools
Very occasionally: VM + realtek-rtl88xxau-dkms + hcxdumptools

additional notes: 8812 also picks up more stations+better signal on them. i definitely don't need MIMO so I think there's no benefit of any kind other than it looks "cool" to have tons of antennas on a thing :p

[ZerBea]

@PixlEmly thanks for the feedback.
hcxdumptool controls the device in a different way than some other tools. I talked with @kimocoder about that regarding the rtl8188eus driver (working, but we have some initialization issues). This control is necessary because we must handle very fast attack vectors. For that we need full access to the device. That includes that we can't share the device with other tools.
hcxdumptool set own monitor mode running ioctl() system calls and verifies that everything is working like expected.
For example, that is working fine on
$ lsusb
ID 7392:7710 Edimax Technology Co., Ltd
$ hcxdumptool -I
wlan interfaces:
74da38eb45fc wlp3s0f0u11u3 (mt7601u)
$ sudo hcxdumptool -i wlp3s0f0u11u3 --check_driver
starting driver test...
driver tests passed - all required ioctl() system calls are supported by driver
restoring old driver settings

$ lsusb
ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
$ hcxdumptool -I
wlan interfaces:
c83a35cb08e3 wlp3s0f0u11u1 (rt2800usb)
$ sudo hcxdumptool -i wlp3s0f0u11u1 --check_driver
starting driver test...
driver tests passed - all required ioctl() system calls are supported by driver
restoring old driver settings

BTW:
the same driver (rt2800usb) doesn't work on RT5370 device...
$ lsusb
ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
$ hcxdumptool -I
wlan interfaces:
7cdd908c166a wlp3s0f0u11u1 (rt2800usb)

$ sudo hcxdumptool -i wlp3s0f0u11u1 --check_driver
starting driver test...
driver tests passed - all required ioctl() system calls are supported by driver
restoring old driver settings
...because of a kernel issue in xhci system, even though if it passed all driver checks
but packet injection isn't working:
WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
https://bugzilla.kernel.org/show_bug.cgi?id=202541

That is the major reason, why I recommend only a few system combinations which are really working without compromises.

Unfortunately rtl8812au and rtl8188eus have some NETLINK initializations inside which doesn't make life easier, because hcxdumptool doesn't use NETLINK protocol to communicate with the driver.

And yes, you're absolutely right with you additional notes:
There are big differences between the chipsets and their configuration:
mt7601u:
INFO: cha=12, rx=6879, rx(dropped)=0, tx=470, err=0, aps=29 (20 in range)
rt2800usb:
INFO: cha=6, rx=3235, rx(dropped)=0, tx=249, err=0, aps=35 (22 in range)
rtl8188eu:
INFO: cha=12, rx=3685, rx(dropped)=0, tx=250, err=0, aps=30 (19 in range)

[ZerBea]

But this is rtl88xxau thread, so let's talk about this driver here. First of all, this driver v5.2.20 (my device is 8811) is working fine.
$ hcxdumptool -I
wlan interfaces:
74da380645e7 wlp0s20f0u3 (rtl88xxau)

$ sudo hcxdumptool -i wlp0s20f0u3 --check_driver
starting driver test...
driver tests passed - all required ioctl() system calls are supported by driver
restoring old driver settings

$sudo hcxdumptool -i wlp0s20f0u3 --do_rcascan
INFO: cha=6, rx=302, rx(dropped)=0, tx=39, err=12, aps=7 (3 in range)

Eveything is working like expected
Now we are doing an AF_NETLINK request, while hcxdumptool is running:

$ sudo iw --debug dev wlp0s20f0u3 info
-- Debug: Sent Message:
BEGIN NETLINK MESSAGE
[NETLINK HEADER] 16 octets
.nlmsg_len = 28
.type = 29 <0x1d>
.flags = 5
.seq = 1567072119
.port = -1195372745
[GENERIC NETLINK HEADER] 4 octets
.cmd = 5
.version = 0
.unused = 0
[PAYLOAD] 8 octets
08 00 03 00 0b 00 00 00 ........
END NETLINK MESSAGE
Debug: Received Message:
BEGIN NETLINK MESSAGE
[NETLINK HEADER] 16 octets
.nlmsg_len = 108
.type = 29 <0x1d>
.flags = 0 <>
.seq = 1567072119
.port = -1195372745
[GENERIC NETLINK HEADER] 4 octets
.cmd = 7
.version = 1
.unused = 0
[PAYLOAD] 88 octets
08 00 03 00 0b 00 00 00 10 00 04 00 77 6c 70 30 ............wlp0
73 32 30 66 30 75 33 00 08 00 01 00 08 00 00 00 s20f0u3.........
08 00 05 00 02 00 00 00 0c 00 99 00 01 00 00 00 ................
08 00 00 00 0a 00 06 00 74 da 38 06 45 e7 00 00 ........t.8.E...
08 00 2e 00 41 00 00 00 05 00 53 00 00 00 00 00 ....A.....S.....
08 00 62 00 08 07 00 00 ..b.....
END NETLINK MESSAGE

and hcxdumptool print error message, because it can't access the device any longer:
failed to transmit undirected proberequest: No such device or address
AF_NETLINK overrides AF_PACKET

Unfortunately we have a similar issue AF_NETLINK on rtl8188eus. In this case, the driver is only initialized if the first message to the driver is an AF_NETLINK message.

I'm still hunting for that issue on rtl88xxau and rtl8188eus, but the driver code is very hard to read: tons of ifdef/endif, debug trace code and user space applications (old hostapd code) inside.

I will say, if the VM takes access to the device - hcxdumptool may not work as expected.

[ZerBea]

Now let's answer the "final question": Why is aircrack-ng suite working?
The answer is easy:
device - driver - AF_NETLINK - libnl - iw - airmon-ng = AF_NETLINK initialized device!
(that is the major reason for hcxdumptool to print a warning if an airmon-ng created monitor mode interface is detected: "warning: wlanxmon is probably a monitor interface")
on the other hand:
device driver - AF_PACKET - hcxdumptool = (device not or only partly initialized)

[ZerBea]

To determine that this issue is possible related to the driver, we are doing exactly the same, running mt7601u driver:

$ hcxdumptool -I
wlan interfaces:
74da38eb4600 wlp3s0f0u11u1 (mt7601u)

$ sudo hcxdumptool -i wlp3s0f0u11u1 --do_rcascan
INFO: cha=1, rx=174, rx(dropped)=0, tx=20, err=0, aps=5 (4 in range)

$ sudo iw --debug dev wlp3s0f0u11u1 info
Debug: Sent Message:
BEGIN NETLINK MESSAGE
[NETLINK HEADER] 16 octets
.nlmsg_len = 28
.type = 29 <0x1d>
.flags = 5
.seq = 1567075593
.port = -851428007
[GENERIC NETLINK HEADER] 4 octets
.cmd = 5
.version = 0
.unused = 0
[PAYLOAD] 8 octets
08 00 03 00 0d 00 00 00 ........
END NETLINK MESSAGE
-- Debug: Received Message:
BEGIN NETLINK MESSAGE
[NETLINK HEADER] 16 octets
.nlmsg_len = 112
.type = 29 <0x1d>
.flags = 0 <>
.seq = 1567075593
.port = -851428007
[GENERIC NETLINK HEADER] 4 octets
.cmd = 7
.version = 1
.unused = 0
[PAYLOAD] 92 octets
08 00 03 00 0d 00 00 00 12 00 04 00 77 6c 70 33 ............wlp3
73 30 66 30 75 31 31 75 31 00 00 00 08 00 01 00 s0f0u11u1.......
09 00 00 00 08 00 05 00 02 00 00 00 0c 00 99 00 ................
01 00 00 00 09 00 00 00 0a 00 06 00 74 da 38 eb ............t.8.
46 00 00 00 08 00 2e 00 45 00 00 00 05 00 53 00 F.......E.....S.
00 00 00 00 08 00 62 00 d0 07 00 00 ......b.....
END NETLINK MESSAGE

Everything is working like expected. hcxdumptool has still full access to the device and rca_scan continued without an error.

BTW:
Tested this also on rt2800usb driver and got exactly the same result. hcxdumptool has still full access to the device and rca_scan continued without an error.

[PixlEmly]

So despite what I said earlier I'm actually seeing wierdness across the driver branches. I can only seem to get any consistency with hcxdumptools under 5.2.20, wifite seems best with 5.6.4 (not .1)

The AWUS1900 seems to have a lot of strange things going on, particularly the signal strength readings are returning impossible values - an AP 2 houses down is certainly not 80db when one 12 feet away only gets 72? (seems like any value under ~25db turns into something silly)

036ACH does get better strength readings on the values that are sensible, and picks up more access points.

Success/failure of different utilites is variable. Works once, stops later. Replug the USB, sometimes it's happy, other times a restart, others still, cleaning out DKMS and adding a driver back in.

I definitely don't have a clean test lab or a good methodology going, but patterns are finally appearing.

Are branches building on previous ones, or is this more of a parallel thing where each branch/version may be ahead/behind various aspects than others?

[ZerBea]

@PixlEmly I refactored the complete handling of ioctl() system calls:
https://github.com/ZerBea/hcxdumptool/commit/95a95d1dd8466a5cec93db8bd2ccfe95212d4b77

If you run
--check_driver, hcxdumptool will check all ioctl() system calls and print error message (this is exactly the error, which is reported by the driver) - some tests are skipped if monitor mode is activated by iw
--do_rcascan, hcxdumptool will inform you whether packet injection is working or not (takes about 13 * 5 seconds)
hcxdumptool in "attack mode", error messages received by the driver are reported, too

I hope, this error messages will help us to hunt for the issue.

BTW:
I'm seeing this "weirdness" across the driver branches, too, but that depends on HAL, provided by Realtek.
Unfortunately, I'm seeing it also within a single branch. Here went something wrong on initialization of the device. Also I'm seeing it in different handling of AF_NETLINK and AF_PACKET sockets.

We had a similar driver issue on mt76 (fixed, yet):
https://github.com/openwrt/mt76/issues/216#issuecomment-500999516

[PixlEmly]

Didn't know it skips checks if iw is used - that's what I've always been doing

another thing I need to test some more - what arguments is wifite using hcxdumptools with for pmkid capture, because it seems to succeed when hcxdumptools by itsef cannot see/poke any stations. might be everything is fine and the card is not really changing channels or transmit is 0mw or something else silly.. and then then wifite with a station selected is setting things where they need to be for success.

[ZerBea]

if iw monitor mode interface we assume that:
iw set monitor mode
iw brought interface up
so we skip this both tests.

During initialization we check that we are able to set all channels in the scan list and we verify that they can be set.
if(ioctl(fd_socket, SIOCGIWFREQ, &pwrq) < 0)
if not, you will be informed:
printf("ioctl(SIOCSIWFREQ) - IW_FREQ_FIXED channel 1 (%dMHz) failed\n", frequency);
drivererrorflag = true;

BTW:
wifite has some issues, too, because it starts hcxtools repeatly:
https://github.com/ZerBea/hcxtools/issues/94

[ZerBea]

If everything is working fine, but after a while no packets are received or are injected, the AF_PACKET socket (which hcxdumptool use) is destroyed by the driver. This is a driver issue, too. I noticed that on older rt2800usb drivers.

Anyway: the interface must be initialized by the driver - that is not part of hcxdumptool or iw or airmon-ng ,....

[PixlEmly]

Still testing variations. :p

Noticed one thing: forcing it to run at USB2 with a usb extension cable has massively improved performance+repeatability. on a test drive:
previous best for 036: 60 unique APs
atheros stick: ~100 APs
036ACH on 2.0 cable saw nearly 450

also, do these rtl88xx have any sort of nonvolatile config I should be aware of or know how to set to a known state?

[ZerBea]

@PixlEmly good investigation:
Length of USB cable play an important part on the cable cross-section used in combination with the power consumption of the device.

Still issues within the init of the devices:
https://github.com/aircrack-ng/rtl8812au/pull/410

Also big differences between chipsets (rca_scan runtime 2 minutes):
EDIMAX EW-7711UAN
ID 7392:7710 Edimax Technology Co., Ltd
INFO: cha=6, rx=7793, rx(dropped)=0, tx=534, err=0, aps=45 (32 in range)

TENDA W311U+
ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
INFO: cha=6, rx=5018, rx(dropped)=0, tx=413, err=0, aps=40 (20 in range)

Tested also rtl8188eus chipsets (TP-LINK WN722 V2) and they are really sensitive (good rx behavior). Would be great to get this driver working, too.

[ZerBea]

BTW:
I really wonder why this driver works like a dream:
$ lspci
3:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821AE 802.11ac PCIe Wireless Network Adapter

$ hcxdumptool -I wlp3s0
wlan interfaces:
b0c090467cab wlp3s0 (rtl8821ae)

$ sudo hcxdumptool -i wlp3s0 --check_driver
starting driver test...
driver tests passed - all required ioctl() system calls are supported by driver
restoring old driver settings

$ sudo hcxdumptool -i wlp3s0 --do_rcascan
initialization...
INFO: cha=6, rx=266, rx(dropped)=0, tx=26, err=0, aps=7 (5 in range)
terminated...

The initialization process is very fast, the card is full initialized and injection is working without problems. I really hope, this will not be over with upcoming rtw88.

[PixlEmly]

Found out:

• I've been running into the same problems as others upstream, but didn't realize it until I comapred outputs more carefully.

• On real machine moving from kernel 4.19 to 5.2.0 solved 5.3.4/5.6.4/5.6.4.1 not working right (5.6.4.1 seems ok and I don't see a reason to mess with the other ones)

Unchanged:

• mbp-mid2012 usb3 is not reliable, have to force ports to run as 2.0 (I have not spent time on this yet.)
• running as 2.0 greatly improves functionality of the 036ACH+AC1900
• 036ACH is still just slightly more sensitive than AC1900
• virtual machine still no go

[fariouche]

for information, note that virtualbox has issues virtualizing usb, especially usb3 device.
The usb stack will loose USB packets (URB), and the usb2 to usb3 switch seems to also confuse virtualbox

[kimocoder]

The USB switch was terrible to start with, wonder if we should just force it down to USB2.0 instead of USB3 ..

[aircrack-ng]

@fariouche, would you happen to have links to bug reports in virtual box?

@kimocoder as an idea, not sure if doable, but maybe have a parameter when loading the module so we let user choose to use usb2 or usb3

[kimocoder]

I may confirm both virtualbox and vmware issues, but never found the issue related to them.

A switch allready exists, I'll find ut tomorrow as I've allready tucked in

[kimocoder]

@ulli-kroll is quite familiar with the USB quircks, maybe he'll leave us his findings/notes here or a solution to our issue

[fariouche]

@aircrack-ng , it was severall month ago...
One old example: https://www.virtualbox.org/ticket/9511?cnum_hist=30&cversion=0

I'm still having issues with virtualbox, (linux host). The device is recognized and connect fine, but the dongle will disappear or act strangely when I start transferring many packets.

[jmaravi]

To summarize. the driver won't work in any VM (vmware/virtual box), correct?

[kimocoder]

I don't think it will, I haven't tested but users says it's not working.

However, frame injection support is suddenly lacking. This will be the priority now!

[kimocoder]

Injection now working for newest branch v5.6.4.2 also, so I'm marking this as resolved for now.
airmon-ng works, wifite2 works and hcxtools (finally) works :+1:

[kimocoder]

Update... branch v5.6.4.2 is working with scapy now.

>>> sniff(iface='wlan0', prn=lambda x: (x.addr2, x.info), lfilter=lambda p: p.haslayer(Dot11ProbeReq))
('00:01:a8:44:47:4a', '')
('00:07:0f:c3:89:29', '')
('00:eb:28:50:b9:10', '')
('00:89:87:04:58:1a', 'Telenor2406dyp')
('ec:0e:c4:a2:e0:1d', 'Telenor4G-FC223C')
('f4:f5:e8:3b:5a:ce', 'Telenor4G-833DD6')
('ec:0e:c4:a2:e0:1d', 'Telenor4G-FC223C')
('fc:03:9f:e3:72:1f', 'S\xc3\xb8rbukta')

[ZerBea]

Great.
But we still have to figure out, why we need NETLINK message (NL80211_IFTYPE_MONITOR) to set monitor mode instead of ioctl(SIOCSIWMODE, IW_MODE_MONITOR).
ioctl(SIOCSIWMODE, IW_MODE_MONITOR) will cause an uninitialized/partly initialized device.
That applies to rtl8188eus driver , too.