NEW upstream driver available!

[kimocoder]

New improved rtl8xxxu upstream. Includes rtl8188e and rtl8188f chips in the mac80211.

[ZerBea]

Huge improvement, compared to the older versions:

$ lsusb
Bus 005 Device 013: ID 2357:010c TP-Link TL-WN722N v2/v3 [Realtek RTL8188EUS]

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 -I
wlan interfaces:
phy2    503eaad2f035    wlp39s0f3u1u1u1 (driver:rtl8xxxu)

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_driver
initialization of hcxdumptool 6.2.7-41-gdce3d1e (depending on the capabilities of the device, this may take some time)...
starting driver test...
detected driver: rtl8xxxu (this driver is not recommended - expect driver errors)
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

I'll remove this warning detected driver: rtl8xxxu (this driver is not recommended - expect driver errors) straight after the driver left beta status.

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 -C
initialization of hcxdumptool 6.2.7-41-gdce3d1e (depending on the capabilities of the device, this may take some time)...
wlp39s0f3u1u1u1 available frequencies, channels and tx power reported by driver:
2412MHz   1 (20 dBm)
2417MHz   2 (20 dBm)
2422MHz   3 (20 dBm)
2427MHz   4 (20 dBm)
2432MHz   5 (20 dBm)
2437MHz   6 (20 dBm)
2442MHz   7 (20 dBm)
2447MHz   8 (20 dBm)
2452MHz   9 (20 dBm)
2457MHz  10 (20 dBm)
2462MHz  11 (20 dBm)
2467MHz  12 (20 dBm)
2472MHz  13 (20 dBm)
2484MHz  14 (30 dBm)

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_injection -c 11
initialization of hcxdumptool 6.2.7-41-gdce3d1e (depending on the capabilities of the device, this may take some time)...
starting antenna test and packet injection test (that can take up to two minutes)...
stage 2 of 2 probing frequency 2462/11 proberesponse 37   
packet injection is working on 2.4GHz!
injection ratio: 52% (BEACON: 111 PROBERESPONSE: 58)
your injection ratio is good
antenna ratio: 100% (NETWORK: 3 PROBERESPONSE: 3)
your antenna ratio is huge - say kids what time is it?

Sometimes it is necessary to reset the device, because connection between USB subsystem and driver get lost:

$ sudo hcxdumptool --reset_usb_device=/dev/bus/usb/005/013
reset successful

Thanks for your excellent work Christian.

[ZerBea]

By this commit: https://github.com/ZerBea/hcxdumptool/commit/b7b258d7674fd150e22687de4609e09c2caefb58 I removed rtl8xxxu driver from the "known as not working list".

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_driver
initialization of hcxdumptool 6.2.7-43-gb7b258d (depending on the capabilities of the device, this may take some time)...
starting driver test...
detected driver: rtl8xxxu
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

[ZerBea]

I still haven't figured out why the device sometimes doesn't respond. Maybe it could be related to this: https://bugzilla.kernel.org/show_bug.cgi?id=202541 But anyway, an USB reset solve the problem.

[ZerBea]

Another device confirmed: TP-LINK TL-WN821N

$ lsusb
ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_driver
initialization of hcxdumptool 6.2.7-43-gb7b258d (depending on the capabilities of the device, this may take some time)...
starting driver test...
detected driver: rtl8192cu (this driver is not recommended - expect driver errors)
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 -C
initialization of hcxdumptool 6.2.7-43-gb7b258d (depending on the capabilities of the device, this may take some time)...
wlp39s0f3u1u1u1 available frequencies, channels and tx power reported by driver:
2412MHz   1 (20 dBm)
2417MHz   2 (20 dBm)
2422MHz   3 (20 dBm)
2427MHz   4 (20 dBm)
2432MHz   5 (20 dBm)
2437MHz   6 (20 dBm)
2442MHz   7 (20 dBm)
2447MHz   8 (20 dBm)
2452MHz   9 (20 dBm)
2457MHz  10 (20 dBm)
2462MHz  11 (20 dBm)
2467MHz  12 (20 dBm)
2472MHz  13 (20 dBm)
2484MHz  14 ( 0 dBm)

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_injection -c 2
initialization of hcxdumptool 6.2.7-43-gb7b258d (depending on the capabilities of the device, this may take some time)...
starting antenna test and packet injection test (that can take up to two minutes)...
stage 2 of 2 probing frequency 2417/2 proberesponse 18   
packet injection is working on 2.4GHz!
injection ratio: 94% (BEACON: 19 PROBERESPONSE: 18)
your injection ratio is huge - say kids what time is it?
antenna ratio: 100% (NETWORK: 7 PROBERESPONSE: 7)
your antenna ratio is huge - say kids what time is it?

terminating...

[ZerBea]

And another one successfully tested: LOGILINK WL0151A

$ lsusb
ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_driver

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
starting driver test...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
detected driver: rtl8xxxu
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 -C

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
wlp39s0f3u1u1u1 available frequencies, channels and tx power reported by driver:
2412MHz   1 (20 dBm)
2417MHz   2 (20 dBm)
2422MHz   3 (20 dBm)
2427MHz   4 (20 dBm)
2432MHz   5 (20 dBm)
2437MHz   6 (20 dBm)
2442MHz   7 (20 dBm)
2447MHz   8 (20 dBm)
2452MHz   9 (20 dBm)
2457MHz  10 (20 dBm)
2462MHz  11 (20 dBm)
2467MHz  12 (20 dBm)
2472MHz  13 (20 dBm)
2484MHz  14 (30 dBm)

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_injection -c 11

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
starting antenna test and packet injection test (that can take up to two minutes)...
stage 2 of 2 probing frequency 2462/11 proberesponse 11   
packet injection is working on 2.4GHz!
injection ratio: 78% (BEACON: 28 PROBERESPONSE: 22)
your injection ratio is excellent, let's ride!
antenna ratio: 100% (NETWORK: 1 PROBERESPONSE: 1)
your antenna ratio is huge - say kids what time is it?

terminating...

[kimocoder]

@ZerBea could you test AP support in 8188eu driver and report back? Also possibly test VIF (airmon-ng start ) support?

[kimocoder]

I still haven't figured out why the device sometimes doesn't respond. Maybe it could be related to this: https://bugzilla.kernel.org/show_bug.cgi?id=202541 But anyway, an USB reset solve the problem.

What kernel version was this tested on? May aswell be the dwc3

[ZerBea]

$ uname -r 6.1.7-arch1-1

An USB reset fix that problem. I guess it is related to XHCI/USB subsystem.

[  561.799403] usb 5-1.1.1: new high-speed USB device number 7 using xhci_hcd
[  561.989749] usb 5-1.1.1: New USB device found, idVendor=2357, idProduct=010c, bcdDevice= 0.00
[  561.989758] usb 5-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  561.989762] usb 5-1.1.1: Product: 802.11n NIC
[  561.989764] usb 5-1.1.1: Manufacturer: Realtek
[  561.989767] usb 5-1.1.1: SerialNumber: 00E04C0001
[  561.990377] usb 5-1.1.1: This Realtek USB WiFi dongle (0x2357:0x010c) is untested!
[  561.990382] usb 5-1.1.1: Please report results to Jes.Sorensen@gmail.com
[  562.051949] usb 5-1.1.1: Vendor: Realtek
[  562.051955] usb 5-1.1.1: Product: 802.11n NIC

BTW: I reported the results to "Jes.Sorensen@gmail.com". No answer, yet.

AP and VIF via iw will follow.

[ZerBea]

VIF test using iw to set VIF monitor interface (airmon-ng is running iw to set monitor mode, so no need to use it):

$ lsusb
ID 2357:010c TP-Link TL-WN722N v2/v3 [Realtek RTL8188EUS]

$ sudo iw phy phy1 interface add mon0 type monitor

$ iw dev
phy#1
    Interface mon0
        ifindex 5
        wdev 0x100000002
        addr 50:3e:aa:d5:e0:35 
        type monitor
        txpower 0.00 dBm
    Interface wlp39s0f3u1u1u1
        ifindex 4
        wdev 0x100000001
        addr 50:3e:aa:d5:e0:35
        type managed
        txpower 0.00 dBm

$ hcxdumptool -I
wlan interfaces:
phy1    503eaad5e035    wlp39s0f3u1u1u1 (driver:rtl8xxxu)
phy1    503eaad5e035    mon0    (driver:rtl8xxxu)

$ sudo hcxdumptool -i mon0 --check_driver

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...

warning: interface mon0 (phy2) is shared
hcxdumptool may not work as expected on shared physical devices

starting driver test...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
detected driver: rtl8xxxu
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

Edited the test result: I started the driver test again, because I forgot use ip link to set the VIF up after it was created by iw. Now every thing looks fine.

AP test will follow (have to set up an environment for the test).

[ZerBea]

Another device tested: ALLNET ALLWA0100

$ lsusb
ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter

$ iwlist
    Supported interface modes:
         * managed
         * monitor

$ hcxdumptool -I
wlan interfaces:
phy12   00e02d0c838e    wlp39s0f3u1u1u1 (driver:rtl8xxxu)

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_driver

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
starting driver test...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
detected driver: rtl8xxxu
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 -C

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
wlp39s0f3u1u1u1 available frequencies, channels and tx power reported by driver:
2412MHz   1 (20 dBm)
2417MHz   2 (20 dBm)
2422MHz   3 (20 dBm)
2427MHz   4 (20 dBm)
2432MHz   5 (20 dBm)
2437MHz   6 (20 dBm)
2442MHz   7 (20 dBm)
2447MHz   8 (20 dBm)
2452MHz   9 (20 dBm)
2457MHz  10 (20 dBm)
2462MHz  11 (20 dBm)
2467MHz  12 (20 dBm)
2472MHz  13 (20 dBm)
2484MHz  14 (30 dBm)

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_injection -c 11

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
starting antenna test and packet injection test (that can take up to two minutes)...
stage 2 of 2 probing frequency 2462/11 proberesponse 12   
packet injection is working on 2.4GHz!
injection ratio: 74% (BEACON: 39 PROBERESPONSE: 29)
your injection ratio is good
antenna ratio: 100% (NETWORK: 2 PROBERESPONSE: 2)
your antenna ratio is huge - say kids what time is it?

terminating...

[ZerBea]

Another device tested: TPLINK TL-WN725N

$ lsusb
ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter

$ iwlist
    Supported interface modes:
         * managed
         * monitor

$ hcxdumptool -I
wlan interfaces:
phy13   1c61b49737f0    wlp39s0f3u1u1u1 (driver:rtl8xxxu)

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_driver

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
starting driver test...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
detected driver: rtl8xxxu
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 -C

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
wlp39s0f3u1u1u1 available frequencies, channels and tx power reported by driver:
2412MHz   1 (20 dBm)
2417MHz   2 (20 dBm)
2422MHz   3 (20 dBm)
2427MHz   4 (20 dBm)
2432MHz   5 (20 dBm)
2437MHz   6 (20 dBm)
2442MHz   7 (20 dBm)
2447MHz   8 (20 dBm)
2452MHz   9 (20 dBm)
2457MHz  10 (20 dBm)
2462MHz  11 (20 dBm)
2467MHz  12 (20 dBm)
2472MHz  13 (20 dBm)
2484MHz  14 (30 dBm)

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_injection -c 11

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
starting antenna test and packet injection test (that can take up to two minutes)...
stage 2 of 2 probing frequency 2462/11 proberesponse 8   
packet injection is working on 2.4GHz!
injection ratio: 64% (BEACON: 28 PROBERESPONSE: 18)
your injection ratio is good
antenna ratio: 100% (NETWORK: 1 PROBERESPONSE: 1)
your antenna ratio is huge - say kids what time is it?

terminating...

[ZerBea]

Another test: EDIMAX EW-7811UN V2

$ lsusb
ID 7392:b811 Edimax Technology Co., Ltd Edimax N150 Adapter

$ iwlist
    Supported interface modes:
         * managed
         * monitor

$ hcxdumptool -I
wlan interfaces:
phy15   08beac305acf    wlp39s0f3u1u1u1 (driver:rtl8xxxu)

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_driver

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
starting driver test...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
detected driver: rtl8xxxu
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 -C

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
wlp39s0f3u1u1u1 available frequencies, channels and tx power reported by driver:
2412MHz   1 (20 dBm)
2417MHz   2 (20 dBm)
2422MHz   3 (20 dBm)
2427MHz   4 (20 dBm)
2432MHz   5 (20 dBm)
2437MHz   6 (20 dBm)
2442MHz   7 (20 dBm)
2447MHz   8 (20 dBm)
2452MHz   9 (20 dBm)
2457MHz  10 (20 dBm)
2462MHz  11 (20 dBm)
2467MHz  12 (20 dBm)
2472MHz  13 (20 dBm)
2484MHz  14 (30 dBm)

terminating...

$ sudo hcxdumptool -i wlp39s0f3u1u1u1 --check_injection -c 11

Warning:
This is a penetration testing tool. It is made to detect vulnerabilities in your NETWORK mercilessly!
Don't report bugs if this tool does exactly what it was coded to do!

initialization of hcxdumptool 6.2.7-48-gadb8a33 (depending on the capabilities of the device, this may take some time)...
BPF is unset. Make sure hcxdumptool is running in a 100% controlled environment!
starting antenna test and packet injection test (that can take up to two minutes)...
stage 2 of 2 probing frequency 2462/11 proberesponse 8   
packet injection is working on 2.4GHz!
injection ratio: 77% (BEACON: 31 PROBERESPONSE: 24)
your injection ratio is excellent, let's ride!
antenna ratio: 100% (NETWORK: 1 PROBERESPONSE: 1)
your antenna ratio is huge - say kids what time is it?

terminating...

[ZerBea]

I'm very impressed with this driver.

[kimocoder]

Awesome, so VIF seem to be working now 👍 Jes Sorensen 🥇

finally got those chips under mac80211, makes me really happy

[ZerBea]

Most of this devices I tested are cheap nano adapters https://www.reichelt.de/de/en/wlan-adapter-usb-150-mbit-s-allnet-allwa0100-p298294.html?&trstct=pol_0&nbc=1 https://www.reichelt.de/de/en/wireless-lan-nano-usb-adapter-150-mbit-s-tplink-tl-wn725n-p123963.html?&trstct=pol_1&nbc=1 https://www.reichelt.de/de/en/wlan-adapter-usb-150-mbit-s-edi-ew-7811un-v2-p293505.html?&trstct=pol_3&nbc=1 except this ones https://www.reichelt.de/de/en/wireless-lan-usb-adapter-300-mbps-tplink-tl-wn821-p92310.html?&trstct=pol_4&nbc=1 https://www.reichelt.de/de/en/wireless-lan-usb-adapter-150-mbit-s-detachable-aerial-tplink-tl-wn722n-p125227.html?&trstct=pol_5&nbc=1

stock drivers must be blacklisted in /etc/modprobe.d $ cat realtek.conf blacklist r8188eu blacklist rtl8192cu

mac80211 stack must be loaded before inserting rtl8xxxu.ko (on first time) $ sudo modprobe mac80211

[kimocoder]

@ZerBea

https://github.com/husqvarnagroup/rtl8xxxu-utils

[ZerBea]

Thanks for that information. I noticed that (maybe similar to the mt76 driver): "Has a Wi-Fi device capable of monitoring the channel used by the AP"

But I gave it up to use active monitor mode, because the disadvantages are huge. It is mandatory to set the MAC address before you send a frame so that the device knows which frame has to be acknowledged. Unfortunately that take too much time.

[dubhater]

• rtl8xxxu does not support AP mode (yet?)

• You should not trust the TX power listed by hcxdumptool any tools with this driver. rtl8xxxu doesn't support getting or setting the TX power (yet?). It always uses the Realtek default, which I don't know what it is.

• Jes Sorensen has not had time for rtl8xxxu since around 2017, so don't expect a reply to your reports. Better send them to linux-wireless@vger.kernel.org - the mailing list for Linux wireless driver development (plain text emails only, no need to subscribe first).

• Packet injection may not work fully. When you're injecting packets you can instruct the driver to use a specific TX rate, right? rtl8xxxu won't honour that for the data frames. You should do a real world test before declaring it good.

[ZerBea]

You should not trust the TX power listed by hcxdumptool with this driver. rtl8xxxu doesn't support getting or setting the TX power (yet?). It always uses the Realtek default, which I don't know what it is.

If tx power is really always the same, it will violate wireless regulatory domain:

$ iw reg set US
$ hcxlabtool -I wlp39s0f3u1u1u3
Requesting interface capabilities. This may take some time.
Please be patient...
interface information:
phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  1   4 00c0cab01a32 00c0cab01a32 + wlp39s0f3u1u1u3  rtl8xxxu (NETLINK & WIRELESS EXTENSIONS)

available frequencies: frequency [channel] tx-power
  2412 [  1] 30.0 dBm     2417 [  2] 30.0 dBm     2422 [  3] 30.0 dBm     2427 [  4] 30.0 dBm
  2432 [  5] 30.0 dBm     2437 [  6] 30.0 dBm     2442 [  7] 30.0 dBm     2447 [  8] 30.0 dBm
  2452 [  9] 30.0 dBm     2457 [ 10] 30.0 dBm     2462 [ 11] 30.0 dBm     2467 [ 12] disabled
  2472 [ 13] disabled     2484 [ 14] disabled
bye-bye

$ iw reg set IN
$ hcxlabtool -I wlp39s0f3u1u1u3
Requesting interface capabilities. This may take some time.
Please be patient...
interface information:
phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  1   4 00c0cab01a32 00c0cab01a32 + wlp39s0f3u1u1u3  rtl8xxxu (NETLINK & WIRELESS EXTENSIONS)

available frequencies: frequency [channel] tx-power

  2412 [  1] 20.0 dBm     2417 [  2] 20.0 dBm     2422 [  3] 20.0 dBm     2427 [  4] 20.0 dBm
  2432 [  5] 20.0 dBm     2437 [  6] 20.0 dBm     2442 [  7] 20.0 dBm     2447 [  8] 20.0 dBm
  2452 [  9] 20.0 dBm     2457 [ 10] 20.0 dBm     2462 [ 11] 20.0 dBm     2467 [ 12] 20.0 dBm
  2472 [ 13] 20.0 dBm     2484 [ 14] disabled

bye-bye

[ZerBea]

Packet injection may not work fully. When you're injecting packets you can instruct the driver to use a specific TX rate, right? rtl8xxxu won't honour that for the data frames. You should do a real world test before declaring it good. This is a baseless insinuation and you're completely wrong

Data rate (set by hcxlabtool): [Data Rate: 13,0 Mb/s] Antenna Signal (tx pwr set by regulatory domain): Antenna signal: -4 dBm Injected frame is type data:

IEEE 802.11 Data, Flags: ....R.F.
    Type/Subtype: Data (0x0020)
    Frame Control Field: 0x080a

Here is the entire (data) frame, received on the second monitor interface:

Frame 272: 158 bytes on wire (1264 bits), 158 bytes captured (1264 bits) on interface wlp39s0f3u1u1u2, id 0
    Section number: 1
    Interface id: 0 (wlp39s0f3u1u1u2)
        Interface name: wlp39s0f3u1u1u2
    Encapsulation type: IEEE 802.11 plus radiotap radio header (23)
    Arrival Time: Mar 22, 2023 13:17:18.517023365 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1679487438.517023365 seconds
    [Time delta from previous captured frame: 0.032499502 seconds]
    [Time delta from previous displayed frame: 0.032499502 seconds]
    [Time since reference or first frame: 27.457298560 seconds]
    Frame Number: 272
    Frame Length: 158 bytes (1264 bits)
    Capture Length: 158 bytes (1264 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: radiotap:wlan_radio:wlan:llc:eapol]
Radiotap Header v0, Length 27
    Header revision: 0
    Header pad: 0
    Header length: 27
    Present flags
        Present flags word: 0xa008402a
            .... .... .... .... .... .... .... ...0 = TSFT: Absent
            .... .... .... .... .... .... .... ..1. = Flags: Present
            .... .... .... .... .... .... .... .0.. = Rate: Absent
            .... .... .... .... .... .... .... 1... = Channel: Present
            .... .... .... .... .... .... ...0 .... = FHSS: Absent
            .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: Present
            .... .... .... .... .... .... .0.. .... = dBm Antenna Noise: Absent
            .... .... .... .... .... .... 0... .... = Lock Quality: Absent
            .... .... .... .... .... ...0 .... .... = TX Attenuation: Absent
            .... .... .... .... .... ..0. .... .... = dB TX Attenuation: Absent
            .... .... .... .... .... .0.. .... .... = dBm TX Power: Absent
            .... .... .... .... .... 0... .... .... = Antenna: Absent
            .... .... .... .... ...0 .... .... .... = dB Antenna Signal: Absent
            .... .... .... .... ..0. .... .... .... = dB Antenna Noise: Absent
            .... .... .... .... .1.. .... .... .... = RX flags: Present
            .... .... .... .... 0... .... .... .... = TX flags: Absent
            .... .... .... ..0. .... .... .... .... = data retries: Absent
            .... .... .... .0.. .... .... .... .... = Channel+: Absent
            .... .... .... 1... .... .... .... .... = MCS information: Present
            .... .... ...0 .... .... .... .... .... = A-MPDU Status: Absent
            .... .... ..0. .... .... .... .... .... = VHT information: Absent
            .... .... .0.. .... .... .... .... .... = frame timestamp: Absent
            .... .... 0... .... .... .... .... .... = HE information: Absent
            .... ...0 .... .... .... .... .... .... = HE-MU information: Absent
            .... .0.. .... .... .... .... .... .... = 0 Length PSDU: Absent
            .... 0... .... .... .... .... .... .... = L-SIG: Absent
            ...0 .... .... .... .... .... .... .... = TLVs: Absent
            ..1. .... .... .... .... .... .... .... = Radiotap NS next: True
            .0.. .... .... .... .... .... .... .... = Vendor NS next: False
            1... .... .... .... .... .... .... .... = Ext: Present
        Present flags word: 0x00000820
            .... .... .... .... .... .... .... ...0 = TSFT: Absent
            .... .... .... .... .... .... .... ..0. = Flags: Absent
            .... .... .... .... .... .... .... .0.. = Rate: Absent
            .... .... .... .... .... .... .... 0... = Channel: Absent
            .... .... .... .... .... .... ...0 .... = FHSS: Absent
            .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: Present
            .... .... .... .... .... .... .0.. .... = dBm Antenna Noise: Absent
            .... .... .... .... .... .... 0... .... = Lock Quality: Absent
            .... .... .... .... .... ...0 .... .... = TX Attenuation: Absent
            .... .... .... .... .... ..0. .... .... = dB TX Attenuation: Absent
            .... .... .... .... .... .0.. .... .... = dBm TX Power: Absent
            .... .... .... .... .... 1... .... .... = Antenna: Present
            .... .... .... .... ...0 .... .... .... = dB Antenna Signal: Absent
            .... .... .... .... ..0. .... .... .... = dB Antenna Noise: Absent
            .... .... .... .... .0.. .... .... .... = RX flags: Absent
            .... .... .... .... 0... .... .... .... = TX flags: Absent
            .... .... .... ..0. .... .... .... .... = data retries: Absent
            .... .... .... .0.. .... .... .... .... = Channel+: Absent
            .... .... .... 0... .... .... .... .... = MCS information: Absent
            .... .... ...0 .... .... .... .... .... = A-MPDU Status: Absent
            .... .... ..0. .... .... .... .... .... = VHT information: Absent
            .... .... .0.. .... .... .... .... .... = frame timestamp: Absent
            .... .... 0... .... .... .... .... .... = HE information: Absent
            .... ...0 .... .... .... .... .... .... = HE-MU information: Absent
            .... .0.. .... .... .... .... .... .... = 0 Length PSDU: Absent
            .... 0... .... .... .... .... .... .... = L-SIG: Absent
            ...0 .... .... .... .... .... .... .... = TLVs: Absent
            ..0. .... .... .... .... .... .... .... = Radiotap NS next: False
            .0.. .... .... .... .... .... .... .... = Vendor NS next: False
            0... .... .... .... .... .... .... .... = Ext: Absent
    Flags: 0x00
        .... ...0 = CFP: False
        .... ..0. = Preamble: Long
        .... .0.. = WEP: False
        .... 0... = Fragmentation: False
        ...0 .... = FCS at end: False
        ..0. .... = Data Pad: False
        .0.. .... = Bad FCS: False
        0... .... = Short GI: False
    Channel frequency: 2437 [BG 6]
    Channel flags: 0x0480, 2 GHz spectrum, Dynamic CCK-OFDM
        .... .... .... ...0 = 700 MHz spectrum: False
        .... .... .... ..0. = 800 MHz spectrum: False
        .... .... .... .0.. = 900 MHz spectrum: False
        .... .... ...0 .... = Turbo: False
        .... .... ..0. .... = Complementary Code Keying (CCK): False
        .... .... .0.. .... = Orthogonal Frequency-Division Multiplexing (OFDM): False
        .... .... 1... .... = 2 GHz spectrum: True
        .... ...0 .... .... = 5 GHz spectrum: False
        .... ..0. .... .... = Passive: False
        .... .1.. .... .... = Dynamic CCK-OFDM: True
        .... 0... .... .... = Gaussian Frequency Shift Keying (GFSK): False
        ...0 .... .... .... = GSM (900MHz): False
        ..0. .... .... .... = Static Turbo: False
        .0.. .... .... .... = Half Rate Channel (10MHz Channel Width): False
        0... .... .... .... = Quarter Rate Channel (5MHz Channel Width): False
    Antenna signal: -4 dBm
    RX flags: 0x0000
        .... .... .... .... .... ..0. = Bad PLCP: False
    MCS information
        Known MCS information: 0x07, Bandwidth, MCS index, Guard interval
            .... ...1 = Bandwidth: Present
            .... ..1. = MCS index: Present
            .... .1.. = Guard interval: Present
            .... 0... = Format: Absent
            ...0 .... = FEC type: Absent
            ..0. .... = STBC streams: Absent
            .0.. .... = Number of extension spatial streams: Absent
        .... ..00 = Bandwidth: 20 MHz (0)
        .... .0.. = Guard interval: long (0)
        MCS index: 1
    [Data Rate: 13,0 Mb/s]
    Antenna signal: -4 dBm
    Antenna: 0
802.11 radio information
    PHY type: 802.11n (HT) (7)
    MCS index: 1
    Bandwidth: 20 MHz (0)
    Short GI: False
    Data rate: 13,0 Mb/s
    Channel: 6
    Frequency: 2437MHz
    Signal strength (dBm): -4 dBm
    [Duration: 120µs]
        [Expert Info (Warning/Assumption): No plcp type information was available, assuming non greenfield.]
            [No plcp type information was available, assuming non greenfield.]
            [Severity level: Warning]
            [Group: Assumption]
        [Expert Info (Warning/Assumption): No stbc information was available, assuming no stbc.]
            [No stbc information was available, assuming no stbc.]
            [Severity level: Warning]
            [Group: Assumption]
        [Expert Info (Warning/Assumption): No extension stream information was available, assuming no extension streams.]
            [No extension stream information was available, assuming no extension streams.]
            [Severity level: Warning]
            [Group: Assumption]
        [Expert Info (Warning/Assumption): No fec type information was available, assuming bcc fec.]
            [No fec type information was available, assuming bcc fec.]
            [Severity level: Warning]
            [Group: Assumption]
        [Preamble: 36µs]
IEEE 802.11 Data, Flags: ....R.F.
    Type/Subtype: Data (0x0020)
    Frame Control Field: 0x080a
        .... ..00 = Version: 0
        .... 10.. = Type: Data frame (2)
        0000 .... = Subtype: 0
        Flags: 0x0a
            .... ..10 = DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x2)
            .... .0.. = More Fragments: This is the last fragment
            .... 1... = Retry: Frame is being retransmitted
                [Expert Info (Note/Sequence): Retransmission (retry)]
                    [Retransmission (retry)]
                    [Severity level: Note]
                    [Group: Sequence]
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = +HTC/Order flag: Not strictly ordered
    .000 0000 1000 0000 = Duration: 128 microseconds
    Receiver address: e8:ca:c8:c3:a9:fb
    Transmitter address: 00:86:a0:12:de:a5
    Destination address: e8:ca:c8:c3:a9:fb
    Source address: 00:86:a0:12:de:a5
    BSS Id: 00:86:a0:12:de:a5
    STA address: e8:ca:c8:c3:a9:fb
    .... .... .... 0000 = Fragment number: 0
    0000 0010 0100 .... = Sequence number: 36
Logical-Link Control
    DSAP: SNAP (0xaa)
        1010 101. = SAP: SNAP
        .... ...0 = IG Bit: Individual
    SSAP: SNAP (0xaa)
        1010 101. = SAP: SNAP
        .... ...0 = CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x3)
    Organization Code: 00:00:00 (Officially Xerox, but
    Type: 802.1X Authentication (0x888e)
802.1X Authentication
    Version: 802.1X-2004 (2)
    Type: Key (3)
    Length: 95
    Key Descriptor Type: EAPOL RSN Key (2)
    [Message number: 1]
    Key Information: 0x008a
        .... .... .... .010 = Key Descriptor Version: AES Cipher, HMAC-SHA1 MIC (2)
        .... .... .... 1... = Key Type: Pairwise Key
        .... .... ..00 .... = Key Index: 0
        .... .... .0.. .... = Install: Not set
        .... .... 1... .... = Key ACK: Set
        .... ...0 .... .... = Key MIC: Not set
        .... ..0. .... .... = Secure: Not set
        .... .0.. .... .... = Error: Not set
        .... 0... .... .... = Request: Not set
        ...0 .... .... .... = Encrypted Key Data: Not set
        ..0. .... .... .... = SMK Message: Not set
    Key Length: 16
    Replay Counter: 63205
    WPA Key Nonce: e8d2100f728224c47e6e4b649bb3d8e3a9ece04ac54dc6e5a852a35a1c657835
    Key IV: 00000000000000000000000000000000
    WPA Key RSC: 0000000000000000
    WPA Key ID: 0000000000000000
    WPA Key MIC: 00000000000000000000000000000000
    WPA Key Data Length: 0

[ZerBea]

I forgot to mention: test interface is an ALFA AWUS036NHV ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter

Monitor interface is an ASUS AC51: ID 0b05:17d1 ASUSTek Computer, Inc. AC51 802.11a/b/g/n/ac Wireless Adapter [Mediatek MT7610U]

And I still recommend this driver in combination with hcxdumptool and hcxlabtool.

[dubhater]

I'm not here to insinuate anything, or criticise the driver. I just know the internals somewhat

[ZerBea]

Ok. But as you can see, data rate can be changed, sucessfuly. TX power can be changed, too. How can we explain that? The monitor interface doesn't lie.

[ZerBea]

I'm not here to insinuate anything, or criticise the driver. Are you sure: "rtl8xxxu won't honour that for the data frames." "You should do a real world test before declaring it good".

[ZerBea]

Some additional information how hcxlabtool change the values (e.g. frequency, rate, bandwidth) by NL80211: https://github.com/ZerBea/wifi_laboratory/blob/main/hcxlabtool.c#L2856 Interface accept it and change its settings (as confirmed by the monitor interface).

[ZerBea]

To make sure, it's no coincidence, I changed the rate via NL80211 to 1MB/sec (that can easily be done by changing some code lines in hcxlabtool). The monitor interface confirmed that the AWUS has transmitted the data frame:

IEEE 802.11 Data, Flags: ....R.F.
    Type/Subtype: Data (0x0020)
    Frame Control Field: 0x080a
    .000 0000 1100 1010 = Duration: 202 microseconds

now with a rate of 1MBit/sec:

Radiotap Header v0, Length 24
    Header revision: 0
    Header pad: 0
    Header length: 24
    Present flags
    Flags: 0x00
    Data Rate: 1,0 Mb/s
    Channel frequency: 2437 [BG 6]
    Channel flags: 0x00a0, Complementary Code Keying (CCK), 2 GHz spectrum
    Antenna signal: -85 dBm
    RX flags: 0x0000
    Antenna signal: -85 dBm
    Antenna: 0

[ZerBea]

If you're right, that the driver doesn't honor this settings, I have to call my entire environment (monitor interface, measurement procedure, Wireshark) into question.

[dubhater]

The TX power issue is very simple. rtl8xxxu only changes the TX power when changing the channel, and it always sets the same power per channel.

The TX rate issue is also simple if your device is RTL8188EU(S). You can insert the module with debug=0x20 and it will tell you what rate it's using for each frame. (Except for the control frames, those are probably always sent at 1M no matter what the driver is saying because it doesn't set TXDESC32_USE_DRIVER_RATE.)

[ZerBea]

Thanks for your explanation.

Maybe we are talking about different things and I apologize for the insinuation: The target of hcxdumptool/hcxlabtool is to retrieve an EAPOL M1 frame (possible including a PMKID) and/or an EAPOL M2 frame (main target - it doesn't matter if the CLIENT is connected to an AP or not), and/or an EAP-ID frame and/or an undirected PROBEREQUEST frame. To make sure we get this frames, we're doing this at lowest bandwidth (20 MHz) and slowest rate 1MBit/sec (benefit: that will increase the range, too). Only this is tested. The driver does it well and I can recommend it exactly for this purpose. I don't care about anything else (e.g. transmitting data) than to request/retrieve this frames.

BTW: After the latest commits, this driver isn't working for me any longer: https://github.com/kimocoder/realtek_rtwifi/issues/36#issuecomment-1479587761 and I use the kernel stock driver.

[ZerBea]

BTW: It looks like we can't trust the debug output of dmesg, too:

hcxlabtool set rate to 6MBit/sec. The independent monitor interface (mt76) confirm that the frames are transmitted with this rate:

802.11 radio information
    PHY type: 802.11g (ERP) (6)
    Proprietary mode: None (0)
    Data rate: 6,0 Mb/s
    Channel: 6
    Frequency: 2437MHz
    Signal strength (dBm): -12 dBm
    [Duration: 200µs]

But dmesg constantly show:

[ 4398.447251] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 93
[ 4398.547965] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 101
[ 4398.648655] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 98

Now the funny part: hcxlabtool set rate to 6MBit/sec.

The independent monitor interface (mt76) report that the frames are transmitted with this rate:

802.11 radio information
    PHY type: 802.11g (ERP) (6)
    Proprietary mode: None (0)
    Data rate: 18,0 Mb/s
    Channel: 6
    Frequency: 2437MHz
    Signal strength (dBm): -12 dBm
    [Duration: 80µs]

and dmesg debug show:

[ 4811.574139] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 95
[ 4811.574683] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 95
[ 4811.700697] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 26
[ 4811.740404] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 26

For me, it looks that: AWSU036NHV and the test target negotiate the rate among themselves - but I'm not sure.

[ZerBea]

Also I can't explain this:

[ 4379.204053] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 18, pkt size 131
[ 4384.946555] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 46
[ 4384.946577] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 17, pkt size 131
[ 4391.096408] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 46
[ 4391.096436] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 16, pkt size 131
[ 4391.131953] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 26
[ 4398.090790] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 15, pkt size 131
[ 4398.129934] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 26
[ 4404.599616] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 14, pkt size 131
[ 4405.082146] usb 3-1.1.2: rtl8xxxu_fill_txdesc_v3: TX rate: 0, pkt size 101

According to the independent monitor interface all frames are transmitted at 6MBit/sec.

[ZerBea]

I code penetration testing tools. Some additional information about my environment: on attack side: interface running hcxlabtool monitor interface running wireshark (not the same chipset as the interface running hcxlabtool)

on target side (target = AP): AP (modified firmware with extended debug information to "see" what the target "see") unmodified standard AP1 (different manufacturer) unmodified standard AP2 (different manufacturer) unmodified standard AP3 (different manufacturer)

on target side (target = CLIENT): modified smart phone (Lineage with extended debug information to "see" what the target "see") standard smart phone (actual Android) standard iPad (actual IOS) Linux notebook running patched wpa_supplicant with extended debug information Linux notebook running standard wpa_supplicant

And sometimes a Spectrum Analyzer (independent measurement). But such a thing is very expensive and I have to borrow it.

Every test start with iw reg set xx to make sure that the driver respect wireless regulatory domain and set the correct country value. Mostly the interface tx power is below this allowed value. I made some measurements with a Spectrum Analyzer and I have to trust this settings.

If hcxlabtool get the information (M1, M2, EAP-ID, undirected PROBEREQUEST as fast as possible (without spamming the entire channel with mostly useless DEAUTHENTICATION frames) the test is successful and this interface/driver can be used with hcxlabtool (and I recommend it). If the test failed (e.g. iwlwifi) I do not recommend interface/driver.

BTW: Errors are reported to bugzilla, e.g.: the driver crashed the entire system: https://github.com/ZerBea/hcxdumptool/issues/245#issuecomment-1373413827

MT7610U incomplete driver information (struct ethtool_drvinfo) https://bugzilla.kernel.org/show_bug.cgi?id=205305

rtl8xxxu failed to get correct interface information: https://bugzilla.kernel.org/show_bug.cgi?id=217231

or to upstream: low tx power m7610e https://github.com/openwrt/mt76/issues/216#issuecomment-500999516

or (in case of a third party driver) directly to the maintainer of this driver: https://github.com/kimocoder/realtek_rtwifi/issues/36#issue-1608706613

But main purpose is to discover weak points of Wireless Systems as this one here: https://github.com/ZerBea/hcxdumptool/issues/246 REASSOCIATION attack cause AP to freeze.

or the this one : PMKID attack: https://hashcat.net/forum/thread-7717.html

or this one (ANONCE ERROR CORRECTION); AP increase last unit32_t of ANONCE instead of REPLAYCOUNTER https://hashcat.net/forum/thread-6361.html

and a lot more... (hcxpsktool).

If you discover a weak point in my test environment, please let me know. That will help me to improve workflow and/or equipment.

[dubhater]

Mystery solved: your injection tool generates a radiotap header where it writes the TX rate you requested. mac80211 reads that rate and passes it on to rtl8xxxu, which ignores it and transmits the frame with whatever rate it wants. Your independent monitor device sees the rate in the radiotap header and reports it to you.

The TX power is also in the radiotap header, but even mac80211 ignores it.

[ZerBea]

Thanks for the explanation. That is correct. hcxdumptool use this this radiotap header to inject frames.

static uint8_t hdradiotap[] =
{
0x00, 0x00, /* radiotap version and padding */
0x0c, 0x00, /* radiotap header length */
0x06, 0x80, 0x00, 0x00, /* bitmap */
0x00, /* all cleared */
0x02, /* rate */
0x18, 0x00 /* tx flags */
};
#define HDRRT_SIZE sizeof(hdradiotap)

Unfortunately hcxdumptool is a WIRELESS EXTENSION dinosaur and outdated. My comments above, e.g.: https://github.com/kimocoder/realtek_rtwifi/issues/34#issuecomment-1401751927 should only demonstrate that the driver respond to an ioctl() request, change channel and show tx power reported by the driver.

Regarding protocol attacks 802.11 on layer 2, tx power is completely meaningless. I commented this several times on hashcat forum and here (lessons learned): TX power is (completely) meaningless - RX sensitivity and a good antenna is all https://github.com/ZerBea/wifi_laboratory BTW: For my tests, I use a country code which has the highest restrictions regarding tx power.

The second mystery is also solved, because hcxlabtool is going a different way (RTNELTLIN/NL80211 instead of WIRELESS EXTENSIONS). It use the smallest possible (injection) radiotap header if it expect a response (e.g. to do an entire AUTHENTICATION):

static u8 rthtxdata[] =
{
0x00, 0x00, /* radiotap version and padding */
0x08, 0x00, /* radiotap header length */
0x00, 0x00, 0x00, 0x00, /* bitmap */
};

or if it doesn't expect a response on the first attempt (fire single frame on first reception of a BEACON):

static u8 rthtxnoackdata[] =
{
0x00, 0x00, /* radiotap version and padding */
0x0a, 0x00, /* radiotap header length */
0x00, 0x80, 0x00, 0x00, /* bitmap */
0x18, 0x00 /* tx flags */
};
#define RTHTXNOACK_SIZE sizeof(rthtxnoackdata)

Set device up and down, set virtual MAC, set monitor mode, set channel is now completely done via RTNETLINK and NL80211. Regarding hcxlabtool I have to go this way to get full benefit of active monitor (e.g. using mt76 devices against target AP to request a PMKID or retry to send frames if CLIENT does not ACK).

And this misunderstanding should now also be clarified: https://github.com/kimocoder/realtek_rtwifi/issues/34#issuecomment-1479496068

[ZerBea]

BTW: I send you a PM to your email address (gmail.com?) from GIT API. If you respond, I'll send you some "real world" tests similar to this one (AWUS036ACH rtl8812au): https://www.cyberark.com/resources/threat-research-blog/cracking-wifi-at-scale-with-one-simple-trick

[kimocoder]

I will start implementing AP mode support this evening.

[dubhater]

@ZerBea Github showed you my email address? That's not very nice of Github.

It's okay, though, you don't have to prove anything to me. I just wanted you to double check, because I had doubts about the driver's capabilities and an automated test may miss something.

[ZerBea]

@dubhater , git API is very useful to retrieve public information: https://api.github.com/users/xxxxxxxxxx/events/public where xxxxxxxxxx is the username.

hcxlabtool in combination with an AWUS036NHV, the rtl8xxxu driver (this one before the last commits and the kernel stock driver) does exactly what I expected (and a little bit more).

@kimocoder , is it worth to add AP mode to hcxlabtool, too. I'm not sure, because I have to set virtual MAC every time I got a new PROBEREQUEST. Doing this via RTNETLINK is not the best/fastest choice. BTW: I prepared some information about results of the driver test. Please let me know, if you're interested (regarding an implementation of hcxlabtool in WiFite2).

[kimocoder]

Hold on, im working on it and I also setup a full debug env for rtl8xxxu through debugfs.

[ZerBea]

For me, it will be only for testing purpose. If I'm able to add AP mode to hcxlabtool, it might be possible to get an EAPOL M2 on interfaces that do not support monitor mode.

[ZerBea]

@kimocoder , please take a look at your PM. The results speak for themselves (~25 % recovered < 4:17 minutes).

[ZerBea]

@kimocoder , maybe interesting for you: https://bugzilla.kernel.org/show_bug.cgi?id=217205 same problem on this driver and the kernel stock driver on rtl8818eu devices: rtl8188eu_rx_iqk_path_a: Path A RX IQK failed!