rtl8xxxu (Linux stock kernel driver) monitor mode and packet injection failed (kernel >= 6.5.0) on chipset RTL8188EUS

[ZerBea]

ALFA AWUS036NHV ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter

$ uname -r
6.6.1-arch1-1

driver: rtl8xxxu (Linux stock kernel driver)

213 packet(s) captured
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
17 EPB written to pcapng dumpfile

exit on EAPOL M1M2
bye-bye

real    0m6,546s
user    0m0,000s
sys 0m0,009s

Important notice: The first attack was successful but the driver died after the first test and device has to be reconnect to the USB port! Neither tshark nor Wireshark nor hcxdumptool received packers any longer.

run hcxdumptool twice:

Warning: no packets received (frame injection may not work as expected)
Possible reasons:
 no AP in range
 frames are filtered out by BPF
 driver is broken
 driver does not support frame injection

1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile

exit on sigterm
bye-bye

confirm that device is in monitor mode:

# iw dev
phy#1
    Interface wlp22s0f0u9u3
        ifindex 4
        wdev 0x100000001
        addr 00:c0:ca:b0:67:e9
        type monitor
        channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
        txpower 20.00 dBm
        multicast TXQ:
            qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes    tx-packets
            0   0   0   0   0   0   0   0       0

run tshark to capture packets:

$ tshark -i wlp22s0f0u9u3
Capturing on 'wlp22s0f0u9u3'
 ** (tshark:5627) 08:24:47.585105 [Main MESSAGE] -- Capture started.
 ** (tshark:5627) 08:24:47.585157 [Main MESSAGE] -- File: "/tmp/wireshark_wlp22s0f0u9u3ZKCRE2.pcapng"
^Ctshark: 
0 packets captured

sometimes dmesg print a warning:

$ dmesg
[ 1697.283905] usb 1-9.3: rtl8188eu_rx_iqk_path_a: Path A RX IQK failed!
[ 1697.418898] usb 1-9.3: rtl8188eu_rx_iqk_path_a: Path A RX IQK failed!
[ 1697.712900] usb 1-9.3: rtl8188eu_rx_iqk_path_a: Path A RX IQK failed!

but mostly not:

$ dmesg
[ 1748.913402] usb 1-9.3: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
[ 1748.913407] usb 1-9.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1748.913410] usb 1-9.3: Product: 802.11n NIC
[ 1748.913411] usb 1-9.3: Manufacturer: Realtek
[ 1751.979371] usb 1-9.3: RTL8188EU rev D (TSMC) romver 0, 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
[ 1751.979377] usb 1-9.3: RTL8188EU MAC: 00:c0:ca:b0:67:e9
[ 1751.979380] usb 1-9.3: rtl8xxxu: Loading firmware rtlwifi/rtl8188eufw.bin
[ 1751.979560] usb 1-9.3: Firmware revision 28.0 (signature 0x88e1)
[ 1756.744526] rtl8xxxu 1-9.3:1.0 wlp22s0f0u9u3: renamed from wlan0
[ 1758.045644] rtl8xxxu 1-9.3:1.0 wlp22s0f0u9u3: entered promiscuous mode

More driver tests and further going information about the test environment: https://github.com/ZerBea/hcxdumptool/discussions/361

The problem is not related to the device itself. All tested RTL8188EUS devices running this driver show the same behavior. https://github.com/ZerBea/hcxdumptool/discussions/361#discussioncomment-7551692 https://github.com/ZerBea/hcxdumptool/discussions/361#discussioncomment-7554097 https://github.com/ZerBea/hcxdumptool/discussions/361#discussioncomment-7554193

It looks like this bug is back again: https://bugzilla.kernel.org/show_bug.cgi?id=217205

RTL8192CU devices are not affected: https://github.com/ZerBea/hcxdumptool/discussions/361#discussioncomment-7554247

[ZerBea]

Re-opened the kernel bug report; https://bugzilla.kernel.org/show_bug.cgi?id=217205#c64

[ZerBea]

The issue is confirmed, now: https://bugzilla.kernel.org/show_bug.cgi?id=217205#c72

[ZerBea]

We got a fix: https://bugzilla.kernel.org/show_bug.cgi?id=217205#c77