Airmon-ng doesn't support RTL8812AU

[SwiftPredator]

Do you want to request a feature or report a bug?

-> Bug

Hey,

as mentioned in many issues before, the program doesn't really support wifi-cards with the RTL8812AU Chipset, because you cant force "airmon-ng start wlan0" on it. So my question is: Were in the bash file i can edit the part were you start "airmon-ng start" with something like this: "ifconfig wlan0 down, iwconfig wlan0 mode monitor, ifconfig wlan0 up". With this option your program would also support those chipsets. I mean my stick supports Injection and monitor mode, but still "airman-ng start" don't work. Just to make it easier to imagine the problem -> When i select the card, the program says that the card isn't supported. I tried to set the card in monitor mode before i start the program, but then the program sticks in the line were it checks for the network cards.

If you don't understand what i want to say, im would be able to give you screenshots and things like that.

Have a nice day and keep up the good work !

PS: Also got the newest Fluxion and Kali-Version.

What is the current behavior?

-> Quit accidentally

---

If the current behavior is a bug, please provide the steps to reproduce.

-> A great way to do this is to provide screenshots and commands.

---

What is the expected behavior?

-> Be creative

---

If this is a feature request, what is motivation or use case for changing the behavior?

---

Specs

Wireless adapter:

Exact model, chipset, and driver versions.

Does it support injection?

Paste the output of aireplay-ng -9

Fluxion version:

Paste the output of cat fluxion.sh | grep revision

Linux version:

Paste the output of cat /proc/version or uname -r

[MPX4132]

Have you tried the following:

# export FLUXIONDropNet=1
# ./fluxion

Check if it works.

[MPX4132]

If you'd like to add your idea, you can do so in the function that runs the interfaces. It's located at line 525 of the fluxion.sh script.

[KatieKate1088]

I had a RTL8812AU as well and tried editing the fluxion code to work but even then the driver is so unstable it caused crashes so I ended up having to switch to an older adapter while I retrofit another driver for this chipset

[MPX4132]

Did it keep doing the “Your wireless card may not be supported” thing, or was fluxion having a fit and bugging out?

[KatieKate1088]

Nah, if I may put in my 2 cents Fluxion in all the times I've used it with the older card has worked flawlessly and I absolutely love it. The biggest thing when using the 8812AU was 1 sometimes monitor mode didn't work and airodump didn't get anything (required some unplugging and replugging) or when it got to the last part of hosting the fake AP it would start up then crash but again this is something on a hardware/driver side of kali not Fluxion.

[MPX4132]

Oh, that’s good to hear. I encountered a very similar problem, and I solved it the same way you did. The adapter’s driver crashed and the program started hanging. I pulled the adapter out and it started working again. This happened with an atheros adapter.

[KatieKate1088]

@MPX4132 Yeah I hope they update those drivers because the tweaks I made to the code were using Iwconfig to change in an out of monitor mode

Sent from my Verizon SM-G935V using FastHub

[Geczy]

https://github.com/FluxionNetwork/fluxion/issues/32

https://github.com/aircrack-ng/aircrack-ng/issues/134

[Geczy]

Why doesn't fluxion just use iwconfig wlan0 mode monitor for greater compatibility with other wifi cards? Replace airmon-ng start and airmon-ng stop

[MPX4132]

Actually, originally, I experimented with that. The original versions of V3 I wrote were using iwconfig, iw, and I forget what else I used. Those never made it to the repo since I forked the project with version control way afterwards. I didn't go the iwconfig way because I imagined the developers here chose airmon-ng for compatibility reasons. If it isn't the case, we can swap it. I was experimenting with iwconfig because I think the program would be more independent, making it a bit more flexible and unlikely to break in the future.

[KatieKate1088]

@MPX4132 That's awesome, that would be great, just to mention, I will work on making the linux drivers compatible with the aircrack suite, because even then using iwconfig the adapter still does crash. The issue is the chipset is new, it supports monitor mode, the drivers do not.

[MPX4132]

Yeah, I'll add it on tomorrow (side-to-side with airmon-ng). I'm working on an update system right now. The current one is completely broken, due to obsolescence.

edit: If I finish early, I'll just add it tonight.

[strasharo]

Does this driver support virtual interface creation? If not the user will have to be forced to use airbase-ng for the fake access point, since we can't have a single interface in both monitor and master mode. Which of course has its downsides, since it's deadly slow.

[BraveLittleRoaster]

Ok I got monitor mode working. Please see edit below, which has news of airodump-ng officially announcing no support for the RTL8812AU chipset

I'm glad I found this. I was ripping my hair out trying to get the RTL8812AU stable.

On mine I have done both v5.1.5 and v4.3.21 here: https://github.com/astsam/rtl8812au

I also tried with the package here: apt-get install realtek-rtl88xxau-dkms

No matter which build, it won't flip into monitor mode with Fluxion, due to airmon-ng not working right with this chipset.

You can flip it into moitor mode though with:

sudo ip link set wlan0 down sudo iwconfig wlan0 mode monitor sudo ip link set wlan0 up

However, when you start airodump-ng, nothing will populate. So some kind of issue with the chipset driver and airodump-ng.

Forcing the band to a so it hops on 5ghz channels yields nothing. Forcing the band to g so it hops on 2.4ghz channels also yields nothing.

Edit: It looks like the RTL8812AU chipset will never have support for Aircrack suite: https://aircrack-ng.blogspot.com/2017/08/on-drivers-rtl8812au-wn722n-monitor.html

They specifically mention:

"RTL8812AU SUPPORT

The driver, from astam, which is also built as a package for Kali, supports monitor mode and injection.

This driver, as is, will most likely never be supported by airmon-ng. The reason is that it is kind of a Frankenstein driver and it doesn't behave the same way any other driver does. It mixes the old ieee80211 stack and the newer mac/cfg80211 stack.

Aircrack-ng tools can be used with it as long as it is in monitor mode but putting it in monitor mode is done in an usual way (check out the README.md on their GitHub for details in the link above)."

So it looks like the Alfa AWUS036ACH and others built off this chipset is a no-go for fluxion or mostly any wireless pentesting or tinkering purposes. The fix would be to flip it into monitor mode using iwconfig, but, has anyone gotten airodump-ng working for this yet? If airodump-ng is working then we can still capture handshakes and use fluxion. Just need to change the way it flips into mon mode.

Edit edit:

GOOD NEWS

Ok, so if you build the v5.1.5 drivers on the latest Kali rolling kernel (4.11.0), and set monitor mode manually, it works for me. I had a conflicting driver from installing the apt package, which I cleared with the purge option.

Steps to get monitor mode working: git clone https://github.com/astsam/rtl8812au cd rtl8812au git checkout v5.1.5 sudo make sudo make install Reboot. If you get build issues, be sure to have your headers installed: sudo apt-get install linux-headers-$(uname -r) or sudo apt-get install linux-headers-amd64

To set the AWUS036ACH into monitor mode, you have to do it with iwconfig: sudo ip link set wlan0 down iwconfig wlan0 mode monitor sudo ip link set wlan0 up Now you can start airodump-ng: airodump-ng wlan0 I'm picking up both 2.4 and 5ghz channels.

So to fix you'd want to maybe add an option to specify switching the interface into mon mode with airmon-ng or with iwconfig, probably after you specify which interface.

[deltaxflux]

Props for this detailed guide.

Edit: I will add it in our wiki

[Geczy]

Wow nice

Maybe we can auto detect this driver in fluxion and print out a message to visit a link which links to your comment

[KatieKate1088]

I'll fork a copy and add the Iwconfig option if you want

[deltaxflux]

@Geczy good idea. Let me try

[deltaxflux]

Update: https://github.com/FluxionNetwork/fluxion/wiki/Patch-driver

[MPX4132]

I had to put upgrading the installer on hold since it's much more time consuming than I anticipated, this seems like a more important issue right now. I just started working on making fluxion airmon-ng independent. I'm using bits of their source, so all credit goes to them.

[Geczy]

Nice!! Can we follow along in your fork

[MPX4132]

I just started a little bit ago, I created this branch in this repository. I'll merge it once done and delete it afterwards.

[MPX4132]

I finished implementation on the branch. It seems like everything is working fine... then I ran an upgrade and now not even the master branch works for me. Damn shame too, lol. edit: hostapd says something along the lines of "...starting RADIUS session..." Even my freaking desktop manager broke after the upgrade (default Kali), and I made not changes to it.

[MPX4132]

Alright, lessev narrowed down the problem to a missing semicolon on the PHP script. Please give the new branch a try and report back the results. My desktop manager is still broken though, so bad news there.

[SwiftPredator]

Hey @MPX4132,

just a little feedback to the new branch. I think i tried it out(airmon-ng wasn't anymore in the fluxion.sh file), but still there are some main problems. First of all, if i don't set the card before using Fluxion into the monitor mode, Fluxion still means that the card isn't supported. If i set the card before using Fluxion into monitor mode, Fluxion sticks at the following output:

[]Unblocking all wireless interfaces... [] Looking for extraneous wireless interfaces... [*] Removing extraneous wireless interfaces...

Thanks and keep up the good work !

[Geczy]

Trying out the airmon-ng-independence branch. It actually works and shows AP's now! Monitor mode is a success.

One problem, while doing the "Handshake Snooper" and I press ctrl c to close the snooper window because the results are present, it freezes with the screen still up

[MPX4132]

@SwiftPredator what you described is what happens when a driver crashes. If you unplug the device while it's still hanging it'll get unstuck, however, that's not a fix, I'm just letting you know what's happening. Can you tell me what happens if you manually set the card to monitor mode with the following:

ip link set wlanX down
iwconfig wlanX mode monitor
ip link set wlanX up

If it works, try starting airodump-ng:

airodump-ng wlanX

If it does not work, check if you can put the interface in monitor mode like so:

ifconfig wlanX down
iwconfig wlanX mode monitor
ifconfig wlanX up

If it works, try starting airodump-ng again. Report back what happens.

It may be a problem with ip since airmon-ng uses it internally to bring devices up and down.

[MPX4132]

@Geczy That's by design, the window needs to stay up so users know the thing caught a handshake. It also stays up when aborted because I can't modify airodump-ng to stop when aborted (I think that was the reason).

[Geczy]

Instructions in the fluxion window would be good...Not sure what to do while that black window is up and running. How long do I wait? Do I type exit? Do I type select another attack? Will it stop automatically?

Maybe a new github issue for this

[MPX4132]

Well, airodump-ng will automatically stop running (it'll halt) but it won't close. It'll become obvious when you don't see anything moving anymore and a handshake has been captured. If you select another attack, it'll be closed automatically.

[SwiftPredator]

Hey @MPX4132,

So now it works great. I just had the wrong version. Still couldnt catch any handshake till now. Even in my own network, but i will try since i got one :)

Thanks for your help!

[MPX4132]

Alright, that's awesome news. If you keep having issues, please report back with the new issue. I'll make some changes to the airmon-ng independent branch to give users the option to revert to it if needed, then I'll merge it with the master branch.

[SwiftPredator]

@MPX4132

I don't know if its normal, but i tried the Handshake snooper on my own network. I started the deauthenfication attack and the handshake capture window starts freezing. I reconnected to my wlan but it seems like fluxion is also freezing in "Handshake sniffer still in progress" state.

Did i do something wrong or is it just like its really hard to get this handshake

Got a WPA2 network.

[Geczy]

Had this issue again, unplug & replug the card worked to fix it...

[Xenophore]

Hey everyone, got a bit strange behavior here or I am missing something. Drivers are installed and due to airodump-ng wlx00c0ca904509 is working fine, I assume they are properly working.

No matter what I try, airmon-ng isn't listing the wifi stick, only the build in wifi interface.

Anyone maybe got an idea what else I can try to solve this issue?

[MPX4132]

@Xenophore I'm not 100% sure about this, but that interface name looks ludicrously long... That will cause an issue when activating monitor mode, since both, fluxion and airmon-ng append an extra three characters to the interface after changing it to monitor mode... Adding three extra characters makes the interface identifier too long, and it fails... I think...

You can check if the card is capable of monitor mode with this:

iw dev wlx00c0ca904509 interface add wlanXmon type monitor

That will create a secondary virtual interface called wlanXmon which is now in monitor mode. I suggest removing the original temporarily:

iw dev wlx00c0ca904509 del

It will be restored when you reboot your system.

[Xenophore]

Okay the virtual interface is listed in airmon. Unfortunately it has an unknown chipset and airmon getting error [phy1]mon0: ERROR while getting interface flags: No such device

I also renamed the device itself so this indeed ridiculous long name is gone but that doesn't help. So I'll assume there could be some incompatibilities with the driver/chipset itself ?

Strange that the monitor mode still can dump data so pure hardware site it should be runnable.

Thanks so far!

Edit: dumping data from wln0 (the real interface) is ok dumping data from wlanmon (the virtual interface) is failing with no error. airodump opens up the capturing screen but nothin is comming in. both tested with airodump

[MPX4132]

Alright, let's clear up some things. I understood you tried what I mentioned about creating a virtual interface and trying to use that. You said the interface looked faulty after checking it with airmon-ng because data was missing. Did you try using that new virtual interface with airodump-ng? If you did, did it work?

Remember that the interface was crated and started in monitor mode, so you shouldn't have to set it to monitor mode anymore. I'm just trying to be extra clear to avoid miscommunication issues.

Also, know that fluxion does not rely on airmon-ng anymore, meaning, it does not use airmon-ng to start monitor interfaces. Instead, it uses an independent small interface management script I wrote (lib/InterfaceUtils.sh).

If virtual interfaces fail, chances are you have a bad driver. I know that RTL chipsets tend to have that problem.

[MPX4132]

@Xenophore By the way, thank you very much for looking through the closed issues. People tend to ignore them and we've got to repeat ourselves.

[Xenophore]

@MPX4132 (was asleep and work) Yes I tried monitoring transitting signals with both interfaces for compairson with airodump-ng. The original interface (renamed to wln0) was working well. The virtual interface did not receive any data. No errors while executing, just the data was missing. What I did not try was deleting 'wln0' after creating 'wlanmon' (the virtual interface).

For sure I did not re-enable the monitor mode on the virtual interface. Created -> Testet

Thanks for trying to avoid miscommunication issues. Always good to care about.

Yes I'm aware about fluxion, the key here is, that I got a lot of automated scripts from a previous machine wich I want to use and they are mostly listing the interfaces to use with this or that via airmon-ng so I have to try to get this running although the interface itself is working properly. If I do some tests manually it is performing well. Capturing and injecting is ok.

I just thought about asking here because it was the closest related conversation to find to this issue.

I also looked at the code of airmon-ng and it seemes that there are hardcoded checks for drivers and chipsets. If this seems to be the case, it could be possible to build an easy workaround with an own check. For me it seems more a software issue than really a driver issue. If it would be so, the interface shouldn't work with airodump-ng.

---

Otherwise if this is not simply to resolve or the issue is resulting in rewriting a bunch of scripts I would consider buying a new more supported interface stick. I picked this one because it's designed for long distances and higher performance. I want to have several accesspoints within our company in range to simultaneously run different pentest attacks. My old netbook died a month ago.

[Xenophore]

Okay I just noticed, that the working interface wln0 is not recognized as an IEEE 802.11 device.

wlanmon   IEEE 802.11  Mode:Monitor  Tx-Power=12 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

wln0      unassociated  Nickname:"<WIFI@REALTEK>"
          Mode:Auto  Frequency=2.412 GHz  Access Point: Not-Associated   
          Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Ok now I'm at the point of "why is it working anyhow".

[pushgfx]

When I set the RTL8812au to monitor mode manually, airodump-ng works after killing extra processes. However, --band abg must be set to hop all the frequencies instead of just 2.8ghz range. Fluxion doesn't seem to be doing this which could easily be fixed, airodump-ng --band abg wlanX. Other than that, Fluxion captures handshakes fine using the RTL8812au, the only remaining issue is getting the captive portal to work which so far I have been unsuccessful. It says "Starting Captive Portal access point service..." and never opens the other windows, just frozen. I suspect this is due to Fluxion using airmon-ng stop/start to move the interface between modes instead of iwconfig.

**Update: Fixed issue of missing frequency bands during initial scanning, line #572 of fluxion.sh from if [ "$channels" ]; then local channelsQuery="--channel $channels"; fi to if [ "$channels" ]; then local channelsQuery="--channel $channels"; else local channelsQuery="--band abg"; fi

[MPX4132]

@pushgfx I just read your comment, sorry this is extremely late. I'll make the changes ASAP.

[kimocoder]

A little update, we've added support for the 88XXau (rtl8812au) into airmon-ng, as we still struggle with virtual Interface support.

airmon-ng noe works with the driver.

[strasharo]

Great news @kimocoder . Just ordered a AWUS036AC, so soon I'll have a device to test with. :)

[alfonsrv]

How does this affect the RTL8812AU's hotspot capabilities? Is a special chipset for that required as well – because currently it will only create a network on 802.11b, making it somewhat useless for Hotspots.