Airmon-ng doesn't support RTL8812AU about fluxion HOT 46 CLOSED

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.

from fluxion.

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.

from fluxion.

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.

from fluxion.

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.

from fluxion.

Have you tried the following:

# export FLUXIONDropNet=1
# ./fluxion

Check if it works.

from fluxion.

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.

from fluxion.

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

from fluxion.

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

from fluxion.

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.

from fluxion.

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.

from fluxion.

@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

from fluxion.

#32

aircrack-ng/aircrack-ng#134

from fluxion.

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

from fluxion.

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.

from fluxion.

@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.

from fluxion.

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.

from fluxion.

Props for this detailed guide.

Edit: I will add it in our wiki

from fluxion.

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

from fluxion.

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

from fluxion.

@Geczy good idea. Let me try

from fluxion.

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

from fluxion.

Nice!! Can we follow along in your fork

from fluxion.

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

from fluxion.

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.

from fluxion.

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 !

from fluxion.

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

from fluxion.

@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.

from fluxion.

@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).

from fluxion.

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

from fluxion.

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.

from fluxion.

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!

from fluxion.

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.

from fluxion.

@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.

from fluxion.

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

from fluxion.

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?

from fluxion.

@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.

from fluxion.

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

from fluxion.

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.

from fluxion.

@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.

from fluxion.

@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.

from fluxion.

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".

from fluxion.

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

from fluxion.

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

from fluxion.

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.

from fluxion.

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

from fluxion.

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.

from fluxion.