Aircrack-ng: A WiFi Auditing Suite That Still Builds From Source

What Aircrack-ng Is Actually For

The README describes Aircrack-ng as "a complete suite of tools to assess WiFi network security" and breaks the work into four areas: monitoring, attacking, testing and cracking. Those four areas map onto different binaries, and the split is the point. You capture with one tool, export to a text file, and process that file with another, which is why the README says all tools are command line and that "a lot of GUIs have taken advantage of this feature."

The audience is narrow. This is for someone auditing a wireless network they are authorised to test, who needs raw 802.11 frames rather than a dashboard. The cracking scope is explicit in the README: WEP and WPA PSK for WPA 1 and 2. Nothing in the README suggests WPA3 or enterprise authentication cracking, so do not read the suite as covering modern WPA3 deployments. The cracking component also needs a captured handshake or a set of WEP frames before it does anything useful; it is the last step, not the first.

The testing area is the one people skip and then regret. Checking WiFi cards and driver capabilities for capture and injection is listed as its own category, and every other category depends on it. If your card cannot inject, the attacking tools are decoration.

How the Suite Is Split Between Capture, Injection and Cracking

The architecture is a set of separate command line programs sharing a common library, not a single daemon. Monitoring produces packet captures and exports data to text files "for further processing by third party tools," which tells you the capture format is meant to be a handoff point rather than a locked container. Attacking covers replay attacks, deauthentication and fake access points, all of which require packet injection through the driver. Testing interrogates the card itself.

That design has a practical consequence for scripting. Because each stage is a process reading and writing files or talking to an interface, you can chain stages in a shell pipeline, run the cracking step on a different machine from the capture step, or feed captures into your own analysis. It also means there is no central state to inspect when something goes wrong. A failed capture and a failed injection look similar at the shell, and the only diagnostic is the tool's own output plus your driver's behaviour.

The optional dependencies reveal where the suite grows beyond its core. PCRE or PCRE2 is needed for SSID filtering with regular expressions in airodump-ng via --essid-regex. SQLite 3.3.17 or newer is needed for airolib-ng and for the -r option in aircrack-ng. libpcap is needed to build besside-ng, besside-ng-crawler, easside-ng, tkiptun-ng and wesside-ng. Airpcap support requires the developer directory from the CD, ISO or SDK. Each of those is a build-time decision, not a runtime toggle, so a distro package built without them will silently lack the capability.

Installing Aircrack-ng on Linux, macOS and Windows

The README lists packages for Arch Linux, Debian stable and testing, Fedora, Homebrew and a long set of Ubuntu releases, so on most systems the first attempt should be the distribution package. On Debian and Ubuntu that is a single apt command, and the binaries land on your PATH.

sudo apt install aircrack-ng

Be aware of what you get. The newest tagged release is 1.7 from 2022-05-10, and distribution packages track their own branches, so the version in your repository may predate it. If you need the current master, build from source instead. The repository ships autogen.sh, configure.ac and a Dockerfile, and the build requires Autoconf, Automake, Libtool, shtool and either the OpenSSL or libgcrypt development package.

./autogen.sh
./configure --with-experimental --with-ext-scripts
make -j$(nproc)
sudo make install

The Dockerfile in the repository builds the same tree inside a Debian base image, running autoreconf, configure with --with-experimental, --with-ext-scripts and --enable-maintainer-mode, then make and make check before installing into a staging directory. That is a reasonable template if you want a reproducible environment rather than a system-wide install. Note that make check runs the test suite and the Dockerfile treats a failure as fatal, printing the relevant test logs.

On Windows the README is blunt: cygwin has to be used, and it also requires the w32api package. If you build with clang you additionally need libiconv and libiconv-devel. That is a source build in a Unix emulation layer, not a native Windows port with an installer, and anyone expecting a double-click setup will be disappointed. macOS is covered through Homebrew and Macports, with gmake required for the Macports path.

For a first real use, the testing step should come before anything else. Run the injection test against your own adapter and read the output, because the README's own framing makes card and driver capability the precondition for the rest of the suite. Only after that should you move to a capture on a network you control.

Where Aircrack-ng Fails or Is the Wrong Choice

The most common failure is not a bug in the suite. It is an adapter that cannot inject, or a driver that reports injection success while dropping frames. The suite has no way to fix that, and the README offers no troubleshooting path for it beyond the testing category. Buy or borrow a card known to work before you spend a day debugging your own scripts.

Airmon-ng, the Linux monitor mode helper, has dependencies that are easy to miss. It requires ethtool, usbutils and often pciutils. The README adds a specific warning: pciutils is only needed if the system has a populated PCI or PCIe bus, and such a bus can be present even when not physically visible. The Raspberry Pi 4 is given as an example, which means a headless Pi build can fail on a dependency nobody expects.

The second mismatch is scope. If your goal is to audit a WPA3 network, or to test 802.1X authentication, the README's cracking section covers WEP and WPA PSK only. If your goal is continuous monitoring of a production wireless estate, a suite built around manual capture and file export is the wrong shape; there is no daemon, no metrics endpoint and no alerting described. And if you need a graphical interface, the README points out that GUIs exist because the command line tools are scriptable, which is an acknowledgement that the suite itself ships without one.

Finally, the release cadence is slow. Between 1.7 in May 2022 and the last push on 2026-09-09 there is no tagged release in the repository. Development continues on master, but anyone pinning to a release is running code from 2022.

Aircrack-ng Against Kismet and Wireshark

Kismet is the closest alternative in intent: a wireless detector, sniffer and intrusion detection system. The difference is architectural. Aircrack-ng is a collection of short-lived command line programs that write files and exit; Kismet is a long-running service with a client interface, built for continuous observation rather than a single capture-and-crack session. If you want to leave a sensor running and review history later, Kismet's model fits. If you want to capture for ten minutes, export the file and run a cracking job in a script, Aircrack-ng's model fits better.

Wireshark is the other comparison people reach for, and it is a different category. Wireshark dissects and displays packets; Aircrack-ng generates the traffic that produces the interesting packets in the first place. The README's monitoring section describes exports "for further processing by third party tools," which is exactly the handoff to a dissector. In practice the two are complementary: capture with Aircrack-ng, inspect with Wireshark, then go back to Aircrack-ng for injection and cracking. Choosing between them is a category error.

The honest comparison is with a modern integrated wireless assessment platform. Those bundle capture, analysis and reporting in one interface. Aircrack-ng gives you the primitives and expects you to build the workflow. That is a real cost in setup time and a real benefit in scriptability.

Maintenance, Licensing and What an Upgrade Costs

The repository is not archived and the last push was on 2026-09-09, so work is happening on master. The release tags tell a different story: 1.7 landed on 2022-05-10, 1.6 on 2020-01-25 and 1.5.2 on 2018-12-09. Anyone who consumes this project through a package manager is, in effect, consuming a snapshot that may be years behind the branch. That gap is the main upgrade cost. Moving from a distribution package to a source build changes your dependency surface, adds Autoconf and Libtool to your build environment, and puts you on the hook for rebuilding when the tree changes.

The repository shows the maintenance effort that goes into keeping a C codebase of this age coherent: CI workflows for Alma Linux, Alpine, DragonFlyBSD, FreeBSD, Gentoo, Kali, Linux, macOS, NetBSD, OpenBSD and Windows, plus Clang scan-build, Coverity Scan and PVS-Studio analysis jobs, a codespell check and a style check. That is a lot of platform coverage for a project whose last tagged release is from 2022, and it explains why the build documentation is longer than the usage documentation. For a build-from-source user, the practical upgrade path is to rebuild and run make check, since the Dockerfile treats a failing test as a build failure.

On licensing: the suite is GPL-2.0, and the repository carries a separate LICENSE.OpenSSL file. The README lists either the OpenSSL development package or the libgcrypt development package as a build requirement, which means the cryptographic backend is a build-time choice with different licence implications depending on which you pick. If you redistribute binaries, or link the suite into a product, that choice is worth reading the two licence files for. This is not legal advice; it is a pointer to the files that govern the question.

Editorial conclusion

Adopt Aircrack-ng if you audit wireless networks you own or are contracted to test, and you are willing to run it on Linux with a card whose capture and injection behaviour you have verified yourself. Do not adopt it as a general purpose network monitor or as a Windows-first desktop tool; the README points Windows users at cygwin and the command line interface is the product. Verify two things before you commit: the version your package manager actually ships, since the newest tagged release is 1.7 from 2022-05-10, and whether your adapter appears in the injection test output, because nothing else in the suite works without that.

Frequently asked questions

Official sources

1. aircrack-ng/aircrack-ng on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases