Packet Injection not working about rtl8188eus HOT 14 OPEN

same problem here ive been facing this problem for an year
actually this is adapter problem like any other adapters... I think u should go for some known working chipset SUCH AS AR9271,RT5372 and even version-1 of this adapter works fine

from rtl8188eus.

Unfortunately, neither an Alfa Adapter or the V1 are found in my country, and ordering from Amazon would be dealing with quite some fees, but I might do it one day. WPS attacks don't work on a lot of routers anyways, as they just lock you out after a few failed attempts, so as long as I can deauth and capture handshakes, i'll bear with what i've got. I'm not sure if creating a fake AP will work though, i'll give it a try sometime.

from rtl8188eus.

It looks like the driver crashes very often, directly after entering promiscuous mode:

[ 618.372330] usb 1-2: new high-speed USB device number 13 using xhci_hcd
[ 618.512989] usb 1-2: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
[ 618.512998] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 618.513005] usb 1-2: Product: 802.11n NIC
[ 618.513010] usb 1-2: Manufacturer: Realtek
[ 618.513015] usb 1-2: SerialNumber: 70F11C27AEEC
[ 618.519468] bFWReady == _FALSE call reset 8051...
[ 618.558160] 8188eu 1-2:1.0 wlp0s20f0u2: renamed from wlan0
...
[ 663.081528] device wlp0s20f0u2 entered promiscuous mode
[ 663.081581] audit: type=1700 audit(1588491052.914:346): dev=wlp0s20f0u2 prom=256 old_prom=0 auid=1000 uid=0 gid=0 ses=2
[ 674.452716] ------------[ cut here ]------------
[ 674.452866] WARNING: CPU: 0 PID: 1274 at /home/zerobeat/temp/rtl8188eus_aircrack-ng/core/rtw_mlme_ext.c:12565 rtw_mlmeext_disconnect+0x117/0x172 [8188eu]
[ 674.452871] Modules linked in: 8188eu(OE) fuse nvidia_drm(POE) nvidia_modeset(POE) nvidia(POE) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_soc_skl snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core i915 rtl8821ae snd_compress ac97_bus btcoexist snd_pcm_dmaengine btusb rtl_pci rtlwifi x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel btrtl kvm_intel snd_intel_dspcfg btbcm btintel kvm rtsx_usb_ms rtsx_usb_sdmmc iTCO_wdt irqbypass joydev bluetooth snd_hda_codec mei_hdcp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel memstick iTCO_vendor_support mmc_core intel_rapl_msr mxm_wmi mac80211 snd_hda_core asus_nb_wmi asus_wmi sparse_keymap i2c_algo_bit aesni_intel nls_iso8859_1 snd_hwdep nls_cp437 ecdh_generic ecc vfat drm_kms_helper snd_pcm crypto_simd fat r8169 cryptd snd_timer glue_helper intel_cstate cfg80211 intel_uncore cec snd realtek intel_rapl_perf rc_core ipmi_devintf rfkill input_leds pcspkr
[ 674.453018] libarc4 i2c_i801 soundcore mei_me libphy intel_gtt ipmi_msghandler syscopyarea sysfillrect processor_thermal_device rtsx_usb intel_lpss_pci sysimgblt i2c_hid intel_rapl_common intel_xhci_usb_role_switch fb_sys_fops mei intel_lpss mousedev roles idma64 intel_soc_dts_iosf intel_pch_thermal elan_i2c tpm_crb int3403_thermal int340x_thermal_zone wmi tpm_tis battery tpm_tis_core ac uvcvideo evdev tpm mac_hid rng_core int3400_thermal acpi_thermal_rel asus_wireless videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc drm sg crypto_user agpgart ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 hid_generic usbhid hid serio_raw atkbd libps2 crc32c_intel xhci_pci xhci_hcd sr_mod cdrom i8042 serio
[ 674.453159] CPU: 0 PID: 1274 Comm: RTW_CMD_THREAD Tainted: P IOE 5.6.8-arch1-1 #1
[ 674.453165] Hardware name: ASUSTeK COMPUTER INC. X555UB/X555UB, BIOS X555UB.301 02/20/2017
[ 674.453291] RIP: 0010:rtw_mlmeext_disconnect+0x117/0x172 [8188eu]
[ 674.453303] Code: 9b f3 c6 83 6a 06 00 00 00 c7 83 6c 06 00 00 00 00 00 00 48 8b 44 24 08 65 48 33 04 25 28 00 00 00 75 5d 48 83 c4 10 5b 5d c3 <0f> 0b e9 39 ff ff ff c6 44 24 01 00 48 8d 54 24 01 be 59 00 00 00
[ 674.453309] RSP: 0018:ffffb6f240acfe60 EFLAGS: 00010286
[ 674.453320] RAX: 0000000080000000 RBX: ffffb6f2402cb000 RCX: 0000000000000000
[ 674.453326] RDX: 0000000000000004 RSI: ffff94e1b8e88a00 RDI: ffffb6f2402cb000
[ 674.453332] RBP: ffffb6f2402cbc62 R08: 0000000000000018 R09: 0000000000000018
[ 674.453338] R10: 00000000000003fc R11: 0000000000000000 R12: ffffb6f2402cc118
[ 674.453344] R13: ffffb6f2402cc0e8 R14: ffff94e19bf60000 R15: ffffffffc1379139
[ 674.453352] FS: 0000000000000000(0000) GS:ffff94e1bbc00000(0000) knlGS:0000000000000000
[ 674.453359] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 674.453365] CR2: 00007fe279e338a8 CR3: 000000019800a002 CR4: 00000000003606f0
[ 674.453370] Call Trace:
[ 674.453521] disconnect_hdl+0x40/0xb4 [8188eu]
[ 674.453618] rtw_cmd_thread+0x268/0x3a9 [8188eu]
[ 674.453640] ? _raw_spin_lock_irqsave+0x26/0x50
[ 674.453655] kthread+0xfb/0x130
[ 674.453747] ? rtw_stop_cmd_thread+0x39/0x39 [8188eu]
[ 674.453756] ? kthread_park+0x90/0x90
[ 674.453770] ret_from_fork+0x35/0x40
[ 674.453789] ---[ end trace ad4066deb79bdcaf ]---
[ 674.455631] device wlp0s20f0u2 left promiscuous mode

BTW:
The first init after the device is plugged in must be done by iw (using NETLINK).
Otherwise ioctl() system calls are not working as expected.
But, if the driver doesn't crash after entering promiscuous mode, packet injection will work:

$ sudo hcxdumptool -i wlp0s20f0u2 --check_driver
initialization...
starting driver test...
interface is already in monitor mode
driver tests passed...
all required ioctl() system calls are supported by driver
terminating...

$ sudo hcxdumptool -i wlp0s20f0u2 --check_injection
initialization...
interface is already in monitor mode
starting packet injection test (that can take up to two minutes)...
packet injection is working!

The same applies to the rtl8812au driver:
aircrack-ng/rtl8812au#587

from rtl8188eus.

Yeah I did do it with iw (the proper way) and aireplay said packet injection is working, but still am unable to inject any packets.

from rtl8188eus.

@Irabz is your libpcap linked against libnl?
$ ldd /usr/lib/libpcap.so
or
$ pcap-config --static --libs
will show you this.

Running Arch linux I'll got this result:
$ ldd /usr/lib/libpcap.so
...
libnl-genl-3.so.200 => /usr/lib/libnl-genl-3.so.200 (0x00007fa99127e000)
libnl-3.so.200 => /usr/lib/libnl-3.so.200 (0x00007fa99125a000)
...

That was the major reason for me to remove libpcap dependency from hcxdumptool/hcxtools completely.

from rtl8188eus.

debian@Debian:~$ sudo airmon-ng check kill

debian@Debian:$ sudo ip link set wlan0 down
debian@Debian:$ sudo iw dev wlan0 set type monitor
debian@Debian:$ sudo ip link set wlan0 up
debian@Debian:$ ldd /usr/lib/libpcap.so
ldd: /usr/lib/libpcap.so: No such file or directory
debian@Debian:$ sudo ldd /usr/lib/libpcap.so
ldd: /usr/lib/libpcap.so: No such file or directory
debian@Debian:$ pcap-config --static --libs
bash: pcap-config: command not found
debian@Debian:~$ sudo pcap-config --static --libs
sudo: pcap-config: command not found
uhh...?

from rtl8188eus.

Thanks for the info. That is exactly the problem.
As far as I know, Debian doesn't link libpcap against libnl:
https://packages.debian.org/de/buster/libpcap-dev
https://packages.debian.org/de/buster/libnl-3-200

Unfortunately iw uses libnl to create a NETLINK monitor interface:

$ sudo iw --debug dev wlp0s20f0u2 set type monitor
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 30 <0x1e>
    .flags = 5 <REQUEST,ACK>
    .seq = 1588671408
    .port = 1233126246
  [GENERIC NETLINK HEADER] 4 octets
    .cmd = 6
    .version = 0
    .unused = 0
  [PAYLOAD] 16 octets
    08 00 03 00 04 00 00 00 08 00 05 00 06 00 00 00 ................
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 2 <ERROR>
    .flags = 256 <ROOT>
    .seq = 1588671408
    .port = 1233126246
  [ERRORMSG] 20 octets
    .error = 0 "Erfolg"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .type = 30 <0x1e>
    .flags = 5 <REQUEST,ACK>
    .seq = 1588671408
    .port = 1233126246
---------------------------  END NETLINK MESSAGE   ---------------------------

At this point we (AF_PACKET) meet an interface initialized by NETLINK and the driver crashed.
I'm hunting for this issue for several weeks, but I haven't found a solution, yet.
Both Realtek drivers (rtl8812au and rtl8188eus) are running into this issue. I haven't noticed this behavior on other drivers (mt76, rt2800usb, ath9k_htc).

If the interface is initialized successfully. before starting hcxdumptool, everything is fine (I have to do this several times):

$ sudo hcxdumptool -i wlp0s20f0u3 --enable_status=64
initialization...
interface is already in monitor mode

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlp0s20f0u3
INTERFACE HARDWARE MAC....: 70f11c27aeec
DRIVER....................: 8188eu
DRIVER VERSION............: 5.6.8-arch1-1
DRIVER FIRMWARE VERSION...: 
ERRORMAX..................: 100 errors
BPF code blocks...........: 0
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ROGUE (ACCESS POINT)......: 586ed67b959d (BROADCAST HIDDEN)
ROGUE (ACCESS POINT)......: 586ed600959e (BROADCAST OPEN)
ROGUE (ACCESS POINT)......: 586ed67b959f (incremented on every new client)
ROGUE (CLIENT)............: d85dfb990727
EAPOLTIMEOUT..............: 20000 usec
REPLAYCOUNT...............: 63933
ANONCE....................: 8e0add9588857850fd1d1f70e6a99f6734417065f5f912049137032a906ea55d
SNONCE....................: e1137fd32080a71647a761f86804522e711256f8eaed4a8fa1b1a8ead3afd5da

11:53:00  11 ERROR:0 INCOMING:4618 OUTGOING:1734 PMKIDROGUE:5 PMKID:0 M1M2ROGUE:0 M1M2:0 M2M3:0 M3M4:0 M3M4ZEROED:0 GPS:0
11:54:00  11 ERROR:0 INCOMING:13542 OUTGOING:4785 PMKIDROGUE:5 PMKID:0 M1M2ROGUE:0 M1M2:0 M2M3:0 M3M4:0 M3M4ZEROED:1 GPS:0
11:55:00  11 ERROR:0 INCOMING:23032 OUTGOING:6793 PMKIDROGUE:7 PMKID:0 M1M2ROGUE:1 M1M2:3 M2M3:3 M3M4:0 M3M4ZEROED:4 GPS:0
11:56:00  11 ERROR:0 INCOMING:31080 OUTGOING:8841 PMKIDROGUE:7 PMKID:0 M1M2ROGUE:1 M1M2:5 M2M3:3 M3M4:0 M3M4ZEROED:4 GPS:0
^C
terminating...

If not, the driver doesn't accept ioctl() system calls and/or crashed:

$ sudo hcxdumptool -i wlp0s20f0u3 --enable_status=64
initialization...
failed to set monitor mode, ioctl(SIOCSIWMODE) not supported by driver: Operation not permitted
warning: failed to init socket
try to use iw to set monitor mode
try to use ip link to bring interface up

terminating...
failed to restore old SIOCSIWMODE: Operation not permitted

As you can see, hcxdumptool is running into the same issue as reaver on this driver.
Unfortunately we need a fast way to communicate with the driver (not via libpcap -> libnl -> rtl8188eus) to perform this attack vector.

BTW:
aireplay-ng is working, because it is compiled against libnl (NETLINK).

from rtl8188eus.

You're right, i'm getting the same outputs as you did with hcxdumptool. I appreciate your detailed response, and I hope with enough effort, we might get packet injection working properly.

from rtl8188eus.

I talked with @kimocoder about this driver behavior. I have an idea, but I'm far away from locating the real cause of this problem. If NETLINK is in use, everything seems to be fine - if not, the driver doesn't initialize the interface completely and we run into this issues.
For me, the use of NETLINK is out of the question, because I don't want to run into this dependency (libnl & libpcap).
And I share this opinion:
https://www.quora.com/What-are-the-differences-between-netlink-sockets-and-ioctl-calls
Running this kind of attack vector (reaver - WPS, hcxdumptool - PMKID), we need a fast and direct communication between application and driver and driver and interface. I don't think NETLINK provide that.

from rtl8188eus.

Regarding NETLINK (libnl) I actually found that the libs used is from a 3rd party fork, not toms311 original one. This was made because the original source was outdated, however now the table has turned and the original source is way more up to date than the 3rd party fork.. I'll notify Kali and Debian over the weekend about it.

from rtl8188eus.

Yeah I did do it with iw (the proper way)

what is the proper way ?

from rtl8188eus.

In case of rtl8188eus and rtl8812au iw is the proper way. Running iw, the driver should initialize the interface via NETLINK message without issues.

from rtl8188eus.

how to change inject rate? it is 1mbps although "pattrib->rate = MGN_24M;".and " iw dev wlan0 set bitrates mcs-2.4 1
command failed: Operation not supported (-95) ".

from rtl8188eus.

I have fixed this bug.but I keep smiling！

from rtl8188eus.