mjhjmtu

I am using a MacBook Pro 2018 and installed the AWUS036ACH Wifi drivers using:

apt-get update
apt-get install realtek-rtl88xxau--dkms

I ran the OS again and reconnected my device (I use a USB hub due to thunderbolt outlets) and ran a series of tests.

It seems to be working for a sec, had injections, then the light went out and it stopped working since.

I see it is still connected but it doesn't seem to be injecting packets any more.

 root@kali:~# iwconfig

wlan0 IEEE 802.11 ESSID:off/any 
 Mode:Managed Access Point: Not-Associated Tx-Power=18 dBm 
 Retry short limit:7 RTS thr:off Fragment thr:off
 Encryption key:off
 Power Management:off

lo no wireless extensions.

eth0 no wireless extensions.



root@kali:~# airmon-ng check kill

Killing these processes:

 PID Name
 706 wpa_supplicant



root@kali:~# airmon-ng start wlan0


PHY Interface Driver Chipset

phy0 wlan0 88XXau Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
 (monitor mode enabled)



root@kali:~# iwconfig

wlan0 IEEE 802.11 Mode:Monitor Frequency:2.457 GHz Tx-Power=18 dBm 
 Retry short limit:7 RTS thr:off Fragment thr:off
 Power Management:off

lo no wireless extensions.

eth0 no wireless extensions.


root@kali:~# aireplay-ng -9 wlan0

19:25:43 Trying broadcast probe requests...
19:25:44 Injection is working!
19:25:45 Found 1 AP 

19:25:45 Trying directed probe requests...
19:25:45 A0:04:60:1E:42:B3 - channel: 9 - 'SLOWWOLFJACK'
19:25:46 Ping (min/avg/max): 1.777ms/6.663ms/22.185ms Power: -40.46
19:25:46 26/30: 86%

root@kali:~# airodump-ng wlan CH 13 ][ Elapsed: 6 s ][ 2019-03-02 19:26 

 BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
 CH 12 ][ Elapsed: 1 min ][ 2019-03-02 19:27 

 BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSIDAR21 

 A0:04:60:1E:42:B3 -41 64 17 0 9 720 WPA2 CCMP PSK SLOWWOLFJACK 
 CC:40:D0:7F:D0:C2 -44 102 104 0 4 195 WPA2 CCMP PSK NETGEAR21 
 BSSID STATION PWR Rate Lost Frames Probe 
 (not associated) 30:8C:FB:05:9E:F6 -33 0 - 1 0 4 NETGEAR21 
 (not associated) 7C:2E:BD:62:F9:52 -35 0 - 1 0 27 NETGEAR21 (not associated) 00:00:48:60:CC:77 -41 0 - 1 48 79 NETGEAR77 
 CC:40:D0:7F:D0:C2 8C:85:90:34:72:10 0 0e- 0e 980 87 NETGEAR21 
 CC:40:D0:7F:D0:C2 2C:AA:8E:09:BA:AA -39 0e- 1 3 14 
 CC:40:D0:7F:D0:C2 64:EB:8C:7B:D4:D7 -45 0 -24 0 3 
 CC:40:D0:7F:D0:C2 74:81:14:A5:EE:E0 -54 1e-24 0 2 
 CC:40:D0:7F:D0:C2 2C:AA:8E:09:1A:C1 -55 0e- 1e 0 17 

root@kali:~# aireplay-ng -9 wlan0
19:27:13 Trying broadcast probe requests...
19:27:15 No Answer...
19:27:15 Found 0 APs

root@kali:~# aireplay-ng -9 wlan0
19:27:18 Trying broadcast probe requests...
19:27:20 No Answer...
19:27:20 Found 0 APs

root@kali:~# aireplay-ng -9 wlan0
19:27:21 Trying broadcast probe requests...
19:27:23 No Answer...
19:27:23 Found 0 APs

root@kali:~# aireplay-ng -9 wlan0
19:27:23 Trying broadcast probe requests...
19:27:25 No Answer...
19:27:25 Found 0 APs

root@kali:~# iwconfig

 wlan0 IEEE 802.11 Mode:Monitor Frequency:2.467 GHz Tx-Power=18 dBm 
 Retry short limit:7 RTS thr:off Fragment thr:off
 Power Management:off

lo no wireless extensions.

eth0 no wireless extensions.

You are showing us in the first place this wireless chipset is capable of injecting packets. Alas, I bet if this procedure is repeated verbatim (not easy), it will behave the same way.

I assume then the question should be more "why does it stop injecting packets after using airodump"? (and not "Wifi is not working"...sorry for flogging a dead horse for making a point, but keep on reading)

It seems to be well known, that WiFi channels have to be changed manually, when using the Alfa AWUS036ACH WiFi chipset in monitor mode.

So, in this session, from the iwconfig output, you started listening to channel 10 (2.457 GHz).

Either there is a step missing, or the BSSID/access point in channel 9 was detected because channel 9 overlaps with the range of channel 10, so the first aireplay was successful.

In the next step, airodump usage changed channels (several times), and left at exit, wlan0 monitoring channel 12 (2.467 GHz).

Subsequently, aireplay injection tests do not work anymore, because you have no nearby APs working on channel 12.

That can be doubly confirmed with the message "Found 0 APs" and also on your airodump output ( 2 APs seen, channels 9 and 4).

TLDR When in monitor mode, airodump is coded for changing channels on it's own for scanning. On the contrary, before using aireplay, you need to change the channel manually in the Wifi chipset, to a channel where there are APs, when using the AWUS036ACH chipset.

I also got a script to change channels for monitor mode in Ubuntu forums Can't Change wlan0 Fixed Channel

#!/bin/bash
# this script is to change the channel of the wireless card to the one specified, then puts it in monitor mode.
# make sure you uncheck enable wireless in nm-applet before continuing (this script will have no effect otherwise)
# note that if you are using airmon-ng you may want to manually remove all of the monitor devices it has created. (you don't need them)
# to do this run "airmon-ng stop mon0" and if you had more then run "airmon-ng stop mon1" etc.

# this script has undefined consequences if the commands fail (no error checking)
# it would be good idea to run each of the commands listed here separately to make sure they all work before making use of this script
# note that this is just sequence of commands which I would normally run manually on my system, they may not work on yours.
# also you need to run the script as root

#change this to the interface you wish to change
IFACE="wlan0"

ifconfig $IFACE down
iwconfig $IFACE mode managed
ifconfig $IFACE up
iwconfig $IFACE channel $@
ifconfig $IFACE down
iwconfig $IFACE mode monitor
ifconfig $IFACE up

PS I advise not (ab)using tools without trying to understand what they are doing.

PPS 2.4GHz Wifi Spectrum standard channels distribution when using 20Mhz channels.