Saturday, September 1, 2018

Debian and FreeBSD on QEMU with MMX-only CPU

A recent bug (and PR) was opened, aircrack-ng couldn't be built with MMX using a i586 toolchain.

The PR looks pretty simple and just removed some code to allow building with MMX. Building the code will obviously work. There isn't a x86 CPU these days that cannot support anything less than SSE2, which was released after MMX.

So, let's take the opportunity to use qemu to emulate a MMX-only CPU so we can actually test how it runs on such CPU after building it.

If you aren't familiar, qemu is known to emulate a lot of different CPUs, most of the time to play (old) games and using non-x86 CPU. It supports a wide range of x86 CPU too. Using it might sound intimidating but it's actually fairly easy.

Pentium MMX, Pentium 2 (and probably Celeron of that same generation) as well as a few AMD support MMX and do not have any SSE/SSE2 instructions.

Another feature in the Pentium 2 is PAE support. Celeron of the same generation typically don't support PAE. Basically, memory was addressed, like the CPU, with 32 bit, which means a limitation of 4Gb of memory. PAE extended this to 64 bit, allowing more memory on 32 bit CPUs. The OS also has to support it.

The vast majority of Linux distributions these days are built with PAE even if they mention they ship in i386/i486. One exceptions: Debian. However, Debian derivative distributions don't support non-PAE systems. CentOS 6 or 7 may work too but they haven't been tested.

In this example, Ubuntu 18.04 64 bit Desktop was used as a host but it should work on any other currently supported OS. We'll download the latest i386 debian ISO (XFCE or netinst) on the host.

First step is to install qemu and required tools:

apt-get install qemu qemu-system-i386 qemu-tools

Now, let's create a disk of 10Gb called hda:

qemu-img create hda 10G

And finally, we start the VM using qemu:

qemu-system-i386 -cpu pentium2,enforce -cdrom debian-9.5.0-i386-xfce-CD-1.iso -m 2G -show-cursor -net user,hostfwd=tcp::1022-:22 -net nic hda

Let's go over the different options.

-cpu pentium2 will use a typical Pentium 2 system. Details of that system can be found by running man qemu-system-i386. The 'enforce' parameter forces to use the instructions of that CPU only. By default, qemu will run executables on the host CPU as shown here, hence why the use of enforce, to fully emulate how a program would behave on that CPU.

The second option, -cdrom debian-9.5.0-i386-xfce-CD-1.iso will mount the ISO inside the emulated system as a CDROM. This option won't be needed when the system is installed.

-m 2G will give 2Gb of RAM to the emulated system. By default, QEmu allocates 128Mb of RAM, which is definitely not enough for Debian; it requires 139Mb. We just raise it to 1Gb to have some margin when we'll run the desktop.

-show-cursor displays the mouse cursor. Otherwise it is invisible.

-net user,hostfwd=tcp::1022-:22 -net nic is initializing a NIC so we can access the virtual machine SSH server from the host. We'll have to connect using ssh -p 1022

And finally hda, the disk we created previously.

A screen will pop up. The installation process is no different than a regular computer; it will just take much longer while because we are emulating a system.

Restarting the virtual machine later on will use the same command as above minus the -cdrom option.

Here is the output of lscpu on the newly created VM:

user@debian:~$ lscpu
Architecture:          i686
CPU op-mode(s):        32-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 5
Model name:            Pentium II (Deschutes)
Stepping:              2
CPU MHz:               2591.957
BogoMIPS:              5183.91
Flags:                 fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 mmx fxsr hypervisor

I bet you never seen a Pentium II overclocked that much :)

Once we got it compiled, to make sure it isn't executed on the host (that supports anything from MMX to AVX2), we will try running the SSE2 version of the executable:

user@debian:~$ aircrack-ng --simd=sse2 -S
Illegal instruction

As expected, it ended up with an Illegal instruction and it means the CPU is fully emulated in the guest (and not executed directly on the host). Anything other than the generic version will result in that error.

So, since the toolchain used is i586, we need to go even further than pentium2 and use the pentium CPU in qemu (P55C). However, we have a serious issue here, there isn't a Linux distribution that supports i586 anymore, not even Debian. If you try to boot it on such platform, it will fail to boot the kernel with a CMOV instruction missing error. So, that would leaves us with Gentoo.

Linux isn't the only option here and BSD supports older CPUs. For example, latest FreeBSD (11.2) still supports i486 CPUs.

The set-up (and results) is identical to what was done for Debian earlier. Installation is straight-forward, exactly the same as you would expect on a real system. And results will be identical.

Tuesday, July 10, 2018

Aircrack-ng 1.3

We're bringing more good stuff in this release. We've been busy fixing bugs left and right, some of them thanks to Coverity Scan, valgrind and other static code analyzers.
We've also refactored some of the code and improved the code quality along the way. We can now successfully build across lots of platforms (Windows, Linux, BSD, OSX) and CPU architectures (x86 and 64 bit, ARM v7, ARM v8, PowerPC, etc)

Aircrack-ng gets a speed bump on pretty much all of the CPU architectures we cover: x86/ARM/PPC. The following graph show the improvements on a Raspberry Pi 3B+.

It may seem that this release is slower than previously (1.2rc3) on non x86 32/64 bit but due to a bug, the cracking speeds were incorrectly calculated. More details can be found in this bug report. On a side note, our benchmark tool is available in build/benchmark.

Here is a benchmark for the NanoPi NEO2:

We had the chance to test Aircrack-ng on a 96-core ARM system ...

... and an IBM Power8 with 160 cores

You can see a significant performance improvement in this release (with the blue line) and you can expect more optimizations in the future, those systems have a lot of potential.

A long-awaited feature has been added: the ability to pause cracking and restart later on. If you intend to pause the cracking at some point in time, start a cracking session with --new-session. You'll be able to restore it using --restore-session. In both cases, the session status is updated every 10 minutes. It works with WEP and WPA/WPA2. Two limitations though: it can only be used with wordlist and they must be files.

Internal changes to aircrack-ng itself and it make is even better than 1.2. It is now back to a single binary. It still compiles the different possible optimizations for a CPU type and loads the fastest optimization based on what the current CPU supports. In the case of x86, the following optimizations will be compiled:
- generic
- SSE2
- AVX2

AVX512 is also available but it is strongly recommended to compile it in only if the CPU running aircrack-ng supports it (configure with --with-avx512).

Support for Jemalloc and tcmalloc was added. They used to provide improvements over the system malloc but testing on Ubuntu 16.04 (x86) showed the system malloc is faster in both cases:

Last, but not least for aircrack-ng, it now supports Hashcat HCCAPx files as input file to crack.

Other changes worth noting:

- Airodump-ng adds a new option to override background detection, --background and can now handle GCMP and CCMP-256 encryption.
- dcrack sees a few improvements, mostly internal fixes as well as a few to better handles errors and corner cases
- Documentation improvements: use of hex wordlists, compilation on OSX, experimental tools compilation
- WPE: Logging Response-Identity and display of NETNTLM hash in Hashcat format for HostAPd-WPE and updated building instructions for Freeradius-WPE 3.0.17
- Code reformatted using clang-format. The formatting file has been provided for use with IDE (or through the command line itself using clang-format)
- Typos fixed thanks to codespell
- and much more!

Sunday, April 15, 2018

Aircrack-ng 1.2

It's been way too long since the last stable release.

Compared to the last stable, 1.1, almost 8 years ago, this release has a huge amount of improvements and fixes. The changelog since 1.1 is almost 300 lines long (1200+ commits). Code quality has improved, in parts thanks to Coverity Scan. We now switched to GitHub completely and have a few buildbots (including one for Windows) to test building and run the test suite on a different platforms.

The build system has switched to autotools, which fixes and improves building on a number of different platforms, CPUs and compilers (gcc, clang and Intel).
Aircrack-ng is now a lot faster on recent CPUs (up to 3 times) and a trampoline binary automatically chooses the best executable for your CPU instructions. There is no need to change any of the commands, it is done transparently. Both those changes will make distro package builder's task easier and they won't have to worry about how to build it to be compatible with the most CPUs.

Continuing with Aircrack-ng, it can also output WPA hashes to EWSA and hashcat format for processing with those tools.

There is 802.11 support in airodump-ng with HT40+/HT40- channels and it now displays the rate correctly for 802.11n or 802.11ac Access Points. For those using GPS, it now supports the recent version of GPSd with JSON.

Airmon-ng itself has a number of improvements in chipset/driver detection. The most notables improvements, on top of new chipset/driver detection, is the support for FreeBSD and on Linux, the support for Nexmon driver (monitor mode driver) on the Raspberry Pi 3 (and 0 Wireless) using Kali. Airtun-ng now supports WPA/2.

For the folks following our release candidates, this doesn't bring much compared to rc5, just a few small fixes and adds UTF8 ESSID support in airodump-ng and aireplay-ng. So, if you are already running 1.2rc5, update is merely advised, otherwise, it is highly recommended.

Changelog from rc5:

  • General: Fixed compiling Windows binaries and updated
  • General: Fixed commands to install dependencies on Debian/Ubuntu and FreeBSD.
  • General: Added command to install dependencies on Fedora/CentOS/RHEL.
  • General: Removed packages/ directory.
  • General: Added Alpine Linux and Kali Linux buildbots.
  • General: Fixed configure with --with-libpcap-include=/somewhere/include and --with-libpcap-lib=/somewhere/lib.
  • General: Fixed search for ethtool when running as a non-root user.
  • General: Various fixes.
  • Airmon-ng: Fixed mktemp on Alpine Linux.

Tuesday, April 3, 2018

Aircrack-ng 1.2 Release Candidate 5

On top of tons of fixes and improvements everywhere (and on multiple platforms), this release switched to autotools which allows compiling on more platforms. A trampoline binary has been added for Aircrack-ng to automatically select the fastest version for your CPU features. It will also help package maintainers greatly.

A few other notable mentions:
  • Airodump-ng supports setting HT40+/HT40- channels and now displays 802.11n and 802.11ac rates.
  • Created WPA Enterprise WPE patches for HostAPd and Freeradius
  • Support to export to HCCAPx for Hashcat v3.6+
  • Added Airventriloquist-ng, a tool from Caesurus.
  • Airmon-ng supports setting Nexmon devices in/out of monitor mode on Kali


  • General: Switching to autotools which allows compiling on more plateforms.
  • General: Updated and INSTALLING files.
  • General: Fixed compilation on a lot of platforms.
  • General: Fixed compilation warnings across platforms and compilers.
  • General: Fixed typos in the tools and in manpages.
  • General: Replace %d/ld with %u/lu for unsigned printf parameters.
  • General: Added option to disable stack protector.
  • General: Improved makefile to get reproducible builds.
  • General: Fixed compilation with OpenSSL 1.1.0.
  • General: Updated radiotap parsing code.
  • General: Updated all URLs to use HTTPS.
  • General: Fixed compilation with libreSSL.
  • General: Added WPS 2.0 test PCAP.
  • General: Do not use stackguard on Windows.
  • General: Fixed warnings on GCC7.
  • General: Improved code quality using Coverity Scan.
  • General: Added badges for Coverity scan and Intel compiler buildbot
  • Aircrack-ng: Use trampoline binary to automatically select fastest executable depending on the CPU
  • Aircrack-ng: Fixed missing include for linecount.
  • Aircrack-ng: Fixed concurrency issues when reading multiple WEP PCAP.
  • Aircrack-ng: Added support for creating HCCAPx file format.
  • Airodump-ng: Get the channel from HT information.
  • Airodump-ng: Detect WPS 2.x.
  • Airodump-ng: Also check current directory for OUI file.
  • Airodump-ng: Fixed writing ESSID to CSV, Kismet CSV and Kismet NetXML files when ESSID gets decloaked and cloaked length was 1.
  • Aireplay-ng: Added deauthentication reason code option.
  • Aireplay-ng: Increase amount of AP to test when running injection test.
  • Airodump-ng: Fixed 802.11a channel hopping list.
  • Airodump-ng: Fix creation of .xor files.
  • Airodump-ng: Added support for HT channels (HT20/HT40-/HT40+).
  • Airodump-ng: Now displaying correct rate for 802.11n or 802.11ac AP.
  • Airmon-ng: Fixed checking for processes.
  • Airmon-ng: Fixed display of "cannot access '/sys/class/ieee80211/': No such file or directory".
  • Airmon-ng: Fixed bashisms.
  • Airmon-ng: Fixed display of specific drivers.
  • Airmon-ng: Fixed display of cards on the sdio bus.
  • Airmon-ng: Now supports nexmon driver on RPi 3 (and 0 Wireless) using Kali Linux.
  • Airmon-ng: Added identification for another realtek chipset and generic Ralink/MT.
  • Airmon-ng: Handle 2 types of rfkill commands and updated unblock text.
  • Airmon-ng: more portable modinfo usage.
  • Airmon-ng: remove grep -P references upon request.
  • Airmon-ng: Do not replace driver name by ?????? when driver is valid.
  • Airgraph-ng: Removed irrelevant comment in README.
  • Airgraph-ng: Handle SSID with double quotes.
  • Airgraph-ng: Fixed parsing OUI file.
  • Airdrop-ng: Updated lorcon2 installation instructions.
  • Besside-ng: Fixed 'wi_read(): No child processes' error.
  • Airdecloak-ng: Fixed segfault due to NULL pointer dereference.
  • osdep: Remove wi_set_channel(1) on open wifi interface (cygwin).
  • osdep: Fixed RAW socket resource leak.
  • Patches: Created WPE patches and documentation for current HostAPd and Freeradius versions.
  • Airodump-ng: Fix incorrect if conditions which always are false.
  • Airodump-ng: Remove useless not NULL check.
  • Airventriloquist: New tool from
  • dcrack: Fixed indentation.
  • TravisCI: Fixed compilation on OSX.
  • AppVeyor: Added support for AppVeyor, CI for cygwin builds.

Sunday, March 11, 2018

Migration to GitHub

We have been wanting to migrate to GitHub for quite some time. We already had subversion to GitHub synchronization, so some of the work was already done. What was left were tickets.
We now finally migrated completely to GitHub.

It was a lot more complicated than what it sounds because we had tickets on trac and issues + pull requests on GitHub. One of the key migration goals was to replicate the data in such a way
as to near perfectly clone it; all while not bothering our entire user base with GitHub notifications.

Joe Benden did most of the work. The same person who helped us migrating to autotools. I did not expect such a level of professionalism and perfectionism in the work. We probably had a total 10 to 15 test-runs, each taking 1 to 2 days to complete and a lot of discussions to find the best solutions to issues/limitations we came across. Each test run was followed by review and feedback to improve it on the next run.

All the trac tickets are correctly linked to each other and have their attachments. We had some ticket numbers skipped in trac, due to spam some time ago. Luckily, GitHub API allows to skip issues numbers. A lot of fine tuning was done to do it the way we wanted. One of the item was linking tickets that was sometimes done in different ways (#123 or or sometimes hxxp:// Even URLs were corrected where needed. Along with a bunch of other small details.

Attachment was a big issue since we wanted to keep them and GitHub pretty much only allows text files or pictures in issues. Anything else is out of question. The best solution we could think about was to store them in a repository, GitHub only limiting large attachments which wasn't a problem in this case. On the filesystem, trac doesn't organize them neatly in directories, by names. Instead, it uses some kind of hashing algorithm and it is necessary to look up in the trac database to match them with the tickets and create a script to batch rename them.

Surprisingly, migrated trac tickets look much better than migrated GitHub issues. They look OK but that is due to GitHub API limitations.

One of the decisions was to avoid spamming people with notifications, so all the tickets are created with the Aircrack-ng account. GitHub doesn't allow to set the creation date or the author (there is a mix or email addresses, anonymous author or just username looking reporters) and with almost 2000 tickets, the best solution was to write down the author and date/time in the issues themselves.

Pull requests is tricky, they can't be migrated from one repo to another, period, even when using the API. So, we now have a copy of the existing ones, without link to the code change. So, if anybody who had a PR in the old repository, if you can recreate it in the new one, it would be great. GitHub API has also some kinds of limitation regarding closed PR/issues.

The reason why we decided to create another repository has to do with importing trac tickets and numbering. Matching would have been way too complicated if we appended to the existing repository. On top of that, if it failed somehow, we had no way of going back. It would also have complicated testing significantly.

Finally, while doing the migration, we noticed that the paid accounts don't have as much rate-limiting as the free accounts and the migration went a lot faster than expected. Just a few hours vs 2 days.

We kept the old repository and renamed it aircrack-ng-archive in case we need to look back at some issue/PR history.

Monday, October 16, 2017

KRACK WPA Vulnerability - Key Reinstallation AttaCK

TL;DR at the end.

Short summary

It is a new vulnerability in the WPA handshake implementation that allows in certain cases to decrypt a lot/all the WPA traffic without knowing the key (and it won't reveal the key).

Most devices are affected but Linux and Android are most affected. Patching will fix the issue.

The attack works if you are connecting to a legitimate access point, which means the attacker has to be in range of both devices. If you are far away from your legitimate AP (such as traveling), it won't affect you.

Proof of concept code (to test the vulnerability) hasn't been published yet.

Who needs to worry?

Businesses and governments are more likely at risk due to (trade) secrets and personal information they handle.

Even though your device(s) are most likely vulnerable, there is no reason to worry. It is a bad flaw but the chances of having it exploited is rare, especially considering the PoC hasn't been published yet.

To put it in comparison, there are still WEP access point around but that doesn't mean they are attacked all the time. However, it isn't a reason to keep vulnerable stuff around, fix (or replace) them.

More details please


  • CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
  • CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
  • CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
  • CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
  • CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
  • CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
  • CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
  • CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
  • CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
  • CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.


  • CWE-323: Reusing a Nonce, Key Pair in Encryption

You might also want to check out Ars Technica (even though their title is a bit dramatic in my opinion), US CERT advisory which includes some affected vendors and the FixKrak website.

How to test it?

Mathy Vanhoef, the author of this vulnerability, posted tools on his GitHub to test AP/client vulnerability.

How to fix it?

Update (or patch) your systems when updates are available, plain simple (and keep them up to date).

Some vendors as well as some Linux distributions already provided a fix and if you keep your devices up to date, then they should already be patched. For other devices, you are dependent on the vendor to provide a patch.

If your (vulnerable) device is End of Life, it might be a good time to replace it (it is probably not be the only vulnerability in it).

A list of vendor responses is available here and here.


Don't worry, another day, another vulnerability. Just patch/update your stuff (computers, cellphone/tablets, AP/routers, IoT) and keep them updated. Businesses/governments should contact their vendors for a patch/press release regarding the vulnerability (devices are not always vulnerable) and if you are running an EoL device, it might be a good time to replace it.

Tuesday, August 15, 2017

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


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.