On drivers, rtl8812au, WN722N, monitor mode, QCA6174, other news and status of linux-backports aka compat-wireless

When discussing in the forum/IRC, it feels that I'm repeating the same things again and again.

I deal with Wi-Fi, play with packets and develop around it every day so all that stuff is fairly easy for me but I realize it is not always obvious. Some of it is because a quick search in THE Google ;) or the Aircack-ng forums or Kali forum would give you the answer.

So here is a summary of some of the things I can think of.

Using another driver

I sometimes see questions or statements like this "This Broadcom driver doesn't work in AP/monitor mode, can I use ath9k for my (Broadcom) card?" or "Can I just use the Airpcap driver to get monitor mode in Windows?"
The answer to both of those is no. Drivers are made for a specific chipset (which is integrated on a wireless card) or a bunch of them that behave similarly.

Some will say this is wrong and they are partially correct: the only choice you have is pretty much VENDOR_DRIVER or open source driver. Where the VENDOR_DRIVER doesn't support monitor mode, so it is out of question. Yes, VENDOR_DRIVER sometimes can be made to support monitor mode, but they won't do it out of the box. Spoiler alert: manufacturers don't care about monitor mode.

You can't just use another driver because the other work better. If you look at the internals in the code, you will see they all are very different. Some of them even require a firmware (and even a specific version) to be loaded so they can work.
Most firmwares are closed source, so if a card behave badly or crashes, the only thing that you can do is bother the manufacturer to fix it, Linux kernel driver developers often can't do much about it.

If you feel adventurous, start developing or fixing bugs in the wireless drivers, Linux kernel developer always need help. If you can't, search and report bugs and provide useful information.

Driver not working for card

This issue got exacerbated recently with rtl8812au and newer cards being released. If you look at drivers, you'll notice that they contains a list of USB IDs (or PCI ID if it's linked to the PCIe bus) for the known cards using the driver.
When a card is plugged on the system, the kernel read its ID and matches it with the appropriate driver.

Developers have a limited set of cards they can test stuff on and new cards with different IDs get released from time to time. So, a driver, even though it will work with a specific card will not be loaded and attached to the card because it doesn't have the IDs. Even if you force loading the driver (modprobe/insmod), it will not work.

An update of that ID table is required to support the new card as well as the driver to be recompiled.

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

Embedded chipsets

Those are tricky and most of them won't support monitor mode and even injection. The reason behind it is those need to use as little power as possible, so your phone can last longer.

With a few exceptions though:

• Raspberry Pi 3 or zero Wireless using Nexmon drivers: monitor mode and injection. For those who played with Kali images with the NexMon driver, if you download the current version of airmon-ng (in our subversion repository), it helps putting the card in monitor mode (even though it's an easy command, it's one less command to remember.
• Nokia N900: Capture and injection in 802.11bg (no n). With a 5000mAh battery and capturing 802.11 frames, the battery will last at most 4 hours and the chip emits a decent amount of heat. That 5000mAh battery usually gives 4-5 days in normal use.
• G1 (I think): same driver as N900 AFAIK.
• ESP8266 (and similar): they seem to support 802.11n in monitor mode (and limited injection?) but those are Arduino-type boards with a 802.11n chip.

So, to sum it up, your Android will most likely not have monitor mode (if you want it, you'll need to use NetHunter and a compatible card).
If you're using iOS, forget it, Apple doesn't care about it, that will never happen.

Monitor mode

We often see people wondering why they can't catch a handshake or data or see any traffic even though their device is connected. What happens is that the card you have probably doesn't support capturing in the mode your connected device is using. Some card that advertise 802.11n/ac capabilities sometimes cannot capture in that mode (and you are limited to 802.11bg), this is either a limitation of the driver/firmware.

802.11n/ac adds some more complexity: it might also not have enough streams (remember those 2x2, 1x1, 3x3?) to capture it: If the station is using 2 stream to send/receive data to the Access Point and your capture card is 1 stream, assuming it can capture in n or ac, will not be able to see the traffic.

There are other possible issues but those are the most common explanations.

QCA6174 (ath10k)

In summary, that card is a PoS. Firmware crashes very often (even for normal operations that would work with any other card) and it is very unlikely it will be fixed. It supports monitor mode but will not give a single packet.

The firmware being closed source, kernel developers are pretty much giving up on that specific chipset.

Ath10k, most of the time, work fine but this specific chipset is doomed. Throw it away and switch to ath9k compatible card, you won't regret it (or just use a supported USB card).
Or if you want to stick with it, you can bother Atheros (now Qualcomm) about it.

TP-Link WN722N

TP-Link recently released a new version of the card (with a different chipset, some Realtek IIRC) and when you buy this card, you don't get the AR9170 chipset (ath9k_htc) anymore.

For those using it in AP mode (as well as any other card using ath9k_htc driver), it has a limitation in the number of stations it can handle (between 5 and 8). It is a physical limitation, not the driver.

Linux-backports, aka compat-wireless

People also misname it to combat-wireless which is pretty funny.

Linux-backports is the latest name and is supposed to bring the latest updates to drivers for pretty much any kernel so you don't have to recompile the whole kernel. Recompiling a kernel is a daunting task, especially if you want to do it right (keep updated with security updates, making sure stuff still work, not breaking other stuff in your distro).

So, when you download, let's say linux-backport-4.1, it will bring the latest updates in the wireless drivers from kernel 4.1. The numbers here refer to the kernel version.

Unfortunately, due to lack of time, they haven't been updated in a long time. If you are able to compile them (most likely not due to the amount of changes), you will downgrade your wireless drivers.

TL;DR: DON'T USE COMPAT-WIRELESS/LINUX-BACKPORTS ANYMORE.

So, any more good news? 

• ath9k works fine in all modes. If you want to create a cheap attack box, look into the PCEngines APU.
• Some Ubiquiti 802.11ac AP can be used to capture in 802.11ac mode (with 3 or 4 streams depending on the unit you buy). Either out of the box or when flashed with OpenWrt.
• If you do a lot of GPU cracking and like AWS, Kali released instances ready to be used with hashcat. No need to install drivers or anything.
• Kali now has a book called Kali Revealed, you can either read it online or buy a hard copy on Amazon.