Wednesday, November 7, 2018

Continuous Integration/Contious Delivery

As mentioned a few times in the changelog and quite a bit in the commits, we have been using a bunch of tools to improve our code quality. And fine tuning them to do more and give us better information. We also use static analysis tools but that step is often done manually.

GitHub has been making it fairly easy to integrate with tools, even custom ones. Their marketplace offers a number of tools to help for development. On top of that, some companies offer to use theirs for free on open source project, which is a great way to improve code quality.

Let's walk through our current CI/CD infrastructure.

We first used Coverity Scan to do static analysis. Even though there are false positives here and there, it's a useful tool. Every single item reported by Coverity explains the path taken that leads to issue. In some cases the complexity of the path is impressive, going through more than 100 conditions. Although it can be integrated with GitHub, it works independently in our case and submitting up to two times a day if there are changes since the last time a build was submitted.

Later on, we added Travis CI. It offers Ubuntu 14.04 and OSX and in both instances, we test using GCC and clang, as well as with gcrypt or openSSL.

We then added AppVeyor to build on Windows. We currently build on cygwin 32 and 64 bit as well as MSYS64 and it builds a package for Windows. With the exception of the package, it tries compiling with GCC and clang in all cases.

If you haven't started doing CI/CD and need to build for Windows, consider using Travis as well as it now supports it.

We then added buildbots. Our buildbots cover current stable versions of:
  • Alpine Linux
  • Kali Linux
  • Kali Linux armel
  • Kali Linux armhf
  • FreeBSD
  • CentOS
We also added a buildbot to test with Intel C++ Compiler.

They all run on the same system with the exception of armel, armhf and FreeBSD that are separate.

And very recently, we added another one to build packages for a number of Linux distributions. It also automatically builds release packages when a new release is tagged in GitHub and it builds git packages whenever code is committed in our repository.

We are now planning to have our own buildbot server to consolidate, simplify and make it easier to manage our buildbot infrastructure. We'll add more systems and possibly use qemu to emulate specific CPUs.

Monday, October 15, 2018

To BE or not to BE? Using Qemu to run a Big Endian Debian system

An issue was reported on a Big Endian system. And, if memory serves right, we had Big Endian bugs a few times in the past.

For readability, we'll refer to Big Endian as BE and Little Endian as LE.

The reason we didn't catch the bug in the first place is, despite the fact that we have extensive testing on multiple OSes, using different compilers and across different CPUs, all our test systems are LE.

Endianness is, basically, the way bytes are organized in memory. We started a long time ago with BE, then got LE systems. Some of them are Bi-endian and can do either BE and LE. Wikipedia has more details if you'd like to read about it

There is a number of CPUs that can run in BE: SPARC, MIPS, PowerPC, ARM and a few others. Like our x86 CPUs, our favorite ARM boards all run in LE but they can also run Big Endian. It was probably easier to run them in LE, less maintenance to do which means developers can focus on the important things: stability and improving hardware support

We could blindly fix the bug in our tests, but being able to test it ourselves would be better and possibly easier. That could possibly open the door to a new buildbot.

Finding a Linux (or BSD) that support it is not easy. Other option for a usable, recent Linux supporting BE is Gentoo, CLFS and possibly Arch. Embedded OS such as OpenWrt is apparently another possibility but it is limited in terms of packages. Unfortunately, Debian dropped support for PowerPC (BE) 2 years ago.

FYI, if you are looking for cheap hardware for a native Big Endian system, look for a Power Mac G5 (or G4) and install FreeBSD powerpc.

That's where qemu is great, as you can see in a previous post. The advantage of doing it in software versus getting physical hardware is that it we can run it along the rest of the buildbots with existing hardware and thus we avoid having to spend extra to power dedicated hardware, its maintenance and rack space.

Initial set-up

First, we need to install qemu and its utilities. We'll use the MIPS architecture in this case, on an Ubuntu 18.04 64 bit host. If you want to try the PPC architecture, this post is a good starting point.

apt install qemu-system-mips qemu-utils

Now, we need to get the appropriate kernel and initrd to do a netboot. You might need to adjust the URL to download the initrd and kernel in the future.

Note: the mips architecture is BE. If we wanted to do LE, we would go with mipsel or mips64el. Same goes for PowerPC, however Debian only offers PPC in LE (ppc64el). All ARM on Debian is LE.


Now, let's create a qcow2 disk image:

user@ubuntu:~$ qemu-img create -f qcow2 disk.img 25G
Formatting 'disk.img', fmt=qcow2 size=26843545600 cluster_size=65536 lazy_refcounts=off refcount_bits=16

  • -f qcow2 specifies the format, qcow2
  • disk.img is the resulting file
  • 25G is the maximum size of the disk inside the image. That size is not allocated immediately, the file will keep growing as changes are done (additions/deletion).
We are allocating much more than we actually need. A base installation would be fine with 2Gb.


Now, let's install Debian on the guest. Bear in mind that the installation will most likely take a few hours:

qemu-system-mips -hda disk.img -kernel vmlinux-4.9.0-7-4kc-malta -initrd initrd.gz -nographic -m 256m

  • -hda points to the disk image
  • -kernel points to the kernel we downloaded
  • -initrd points to the netboot install initrd
  • -nographic will not open a graphic interface and display output in the current console
  • -m 256m gives 256Mb of memory to the guest. 32 bit kernels are limited to 256Mb of RAM (if unspecified, default for qemu is 128Mb). 64 Bit MIPS qemu can get up to 2047Mb but there isn't any Debian for that. If you were to use more than 256Mb, adding "mem=256m@0x0 mem=XXXm@0x90000000" to -append (where XXX is the amount in -m minus 256Mb) might be needed

Note: mips64 would have been preferable because it can support more RAM but Debian doesn't offer that architecture.

It will start in the console. Simply follow the instructions like you would install a regular Debian system. The only two important choices that were made here, were to install all files in a single partition (and use the simple guided process when partitioning) and not install any X system due to the low memory.

At the end of the installation, a warning windows will be displayed mentioning there is no bootloader installed. It is expected, so it's fine.

A few moments later, Debian will let you know the installation is done. It will not shutdown but reboot (and restart with the netinstall if we let it). Interrupt the process by closing the terminal window (or hit Ctrl + a, c then input the command 'quit' to stop it).


The initrd we downloaded earlier is for netinstall only it won't work to boot our system. We'll need to grab the one generated during the installation. For this, we'll mount the qcow2 image we just installed, disk.img. One way to mount it is to use the tools included with Qemu.

We first need to load nbd module:

sudo modprobe nbd

Then we connect the image to /dev/nbd0 and mount its first partition (because we installed all the files in a single partition) somewhere on our host:

mkdir qcow
sudo qemu-nbd --connect=/dev/nbd0 disk.img
sudo mount /dev/nbd0p1 qcow

From there, we'll copy the initrd from /boot then unmount it and disconnect the image:

cp qcow/boot/initrd.img-4.9.0-7-4kc-malta .
sudo umount qcow
sudo qemu-nbd --disconnect /dev/nbd0

rmdir qcow

Now, let's update our above command line to run our newly installed system:

sudo qemu-system-mips -hda disk.img -kernel vmlinux-4.9.0-7-4kc-malta -initrd initrd.img-4.9.0-7-4kc-malta -append "root=/dev/sda1" -nographic -m 256m -net user,hostfwd=tcp::1022-:22 -net nic

We also added forwarding to access SSH on the system. Refer to the previous blog post for more details about it.

After booting, we're greeted with a familiar prompt:

Debian GNU/Linux 9 debian ttyS0

debian login:

After logging in with the credentials we configured during the installation, running lscpu will give the following result:

root@debian:~# lscpu
Architecture:          mips
Byte Order:            Big Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
BogoMIPS:              1161.21

Which confirms it's a BE system. There are a number of other ways to determine that.

Updating the system will bring a new kernel, and we'll simply have to follow the same procedure as described above when we copied the initrd. In this case, get both the new kernel and its corresponding initrd then adjust the qemu command line once again for the next time we boot it (update both -kernel an -initrd entries):

sudo qemu-system-mips -hda disk.img -kernel vmlinux-4.9.0-8-4kc-malta -initrd initrd.img-4.9.0-8-4kc-malta -append "root=/dev/sda1" -nographic -m 256m -net user,hostfwd=tcp::1022-:22 -net nic

Here is what the updated system looks like (uname -a):

Linux debian 4.9.0-8-4kc-malta #1 Debian 4.9.110-3+deb9u5 (2018-09-30) mips GNU/Linux


The qcow2 image will keep growing even if we remove packages or delete files. Reclaiming free space is just a matter of zero'ing the disk space left in the guest then recompressing the image on the host after powering it off.

The first step is to fill the disk with zero's in the guest using dd then deleting the file. Make sure you have enough disk space on the host before you do that:

dd if=/dev/zero of=zerofile
rm -f zerofile

Deleting the file is very important or you may end up with an unbootable system. If that happens, just mount the qcow2 image like shown above and delete the file.

When done, shut the guest down. If you look at the file, disk.img, on the host, it will take the amount of space we initialized it with, 25Gb. Now, recompress it:

mv disk.img disk.img.bak
qemu-img convert -O qcow2 disk.img.bak disk.img

After installation and updates, it took approximately 1.8Gb and recompressed, 1.6Gb, saving roughly 200Mb.

Now, enjoy your new MIPS Big Endian system. Compiling aircrack-ng inside is exactly the same procedure as you would do on a regular x86 Debian system.

Saturday, October 6, 2018

Aircrack-ng packages

As mentioned in our 1.4 release blog post, we are now providing packages (repositories) for a "few" Linux distributions (and sometimes multiple version of each of them):
  • Debian
  • Ubuntu
  • Mint
  • SLES
  • OpenSuse
  • Fedora
  • RHEL
  • CentOS
  • Amazon Linux
  • Elementary OS
TL;DR: if all you want is to install the package, head over here.


Packages are an easy and convenient way to install software compared to compiling it.

All you have to worry about, after installing a package, is to make sure your system is up to date and there is no need to worry about each individual piece of software anymore. Today's distributions often even check automatically and notify if updates are available.

Another reason is that most Linux distributions often have old versions of Aircrack-ng in their repository and sometimes are a few years old.

It can be a problem for us when providing support. We often end up telling people to uninstall and recompile the latest release or try the current development code where the bug they're experiencing is fixed.

If you're a software developer, it's not too hard to figure out how to compile a piece of software, as long as the software is current and is documented. However, in some cases, it can get complicated.
And if you're not a developer, it is a daunting task.

We recently decided to tackle this issue and provide recent versions via packages, and for multiple OSs.

Why not a snap or a flatpak?

There are more than just those two possibilities as you can see in this post and all of those software are still not widely adopted yet. We may, in the future, offer snaps or flatpaks.


For CI/CD, we have been using buildbots on top of Travis CI and AppVeyor to automatically build Aircrack-ng on multiple platforms and multiple distros. It happens to every commit done to the master branch in our GitHub repository

We recently added a packages building bot to the buildbots for all the distributions mentioned on top.

Building packages and dependencies

Creating packages for that many distributions is not easy and if we did it the same way package managers do, we would have to keep spending a considerable amount of time and resources. So, the decision was made that the best route was to statically compile latest version of the dependencies into Aircrack-ng.

Basically, all the dependencies needed for each binary are built into each of them and what that means practically is that you can take the executable and just copy and paste it on another distro, no matter what packages are installed on that distro and how old or outdated it is, it would just work.

It wasn't an easy feat.

There is a drawback, the binaries are larger than if they were coming from the distribution itself (or if you were compiling them yourself with the default options), because they are dynamically linked to its dependencies, which are sometimes shared with other software.

There is also a huge advantage. As mentioned above, we can support multiple OS and multiple versions of each of these OS easily and  as a bonus, you will always have the latest version of the dependencies which are, most of the time, newer than what your distribution is providing. Added bonus: it sometimes fix bugs found in the library available in the distro.



Maintaining repositories to distribute the packages was another issue, we could have gotten an Ubuntu PPA repository, our own repository for Debian, the different derivatives of SuSe and RedHat but maintaining repositories for different distributions is a time and resources consuming task. So, we went with to handle it.

They provides instructions on how to add each of the repositories, either manually or automatically via their script. Afterward, it is just a matter of installing or updating Aircrack-ng via your package manager.

As mentioned, two flavors are available:
  • release: Any release published on our website, starting from this release, 1.4
  • git: for the most adventurous, built from each commit in our GitHub repository, with the latest features and bug fixes. While our repository is fairly stable, it may sometimes have bugs
Providing packages also means our package is a drop-in replacement for the existing Aircrack-ng package available from your distro and it will still be working with any package that requires it as a dependency.


Windows doesn't have any package manager we can leverage. Development binaries for Windows, built from our GitHub repository, are available on AppVeyor. On that link, select the last target, pkg, then click on the Artifacts tab.


To make our life easier so we can focus on the development, it is, like all the CI/CD, automated thanks to our buildbots. The magic sauce is in packages.yaml in build/pipelines.


If your distribution is providing an up to date package of Aircrack-ng, we recommend to use it instead of our packages. That is, unless you are using the git packages.

If your distribution isn't in the list of supported ones but uses DEB or RPM packages, you can try overriding the distribution in PackageCloud installation script

If you have any question about it, please head to our forum.

Saturday, September 29, 2018

Aircrack-ng 1.4

We are pleased to announce our third release this year. It focuses a lot on code quality and adds a few visible features:
  • PMKID cracking
  • Crack 802.11w capture files
  • Speed and memory usage improvement when loading (large) files with Aircrack-ng and Airdecap-ng
  • Packages for Linux distributions and Windows
While we didn't bring as much as in the previous release, we keep on improving continuous integration/delivery tools and our code quality keep increasing.

Other notable changes in this release:
  • Fix building on various platforms
  • Improved and tweaked our CI/CD processes
  • Using new CI/CD tools for our buildbots and packaging, PyDeployer
  • Almost doubled the amount of tests


On routers with 802.11i/p/r, the AP can cache an "ID" for the connection so roaming clients don't have to waste frames reauthenticating and just use the PMKID, which helps decrease a bit the latency (from 6 frames to only 2).

Calculation is of the PMKID is done this way:


A big advantage here is that this PMKID is present in the first EAPoL frame of the 4-way handshake.

A few caveats about this attack:
  • Sometimes APs send empty PMKID
  • It doesn't work on WPA/WPA2 Enterprise networks

When loading a PCAP, Aircrack-ng will detect if it contains a PMKID. In the following screenshot, it is present for the network ogogo, notice the "with PMKID" on the same line:

When selecting the network, it will use it as if it were a regular PCAP with a handshake (and thus the wordlist requirement applies).

If you'd like to test, two capture files with PMKID are available in our test files:

More details about the attack itself can be found in this post.


Distros often have old versions of Aircrack-ng in their repository. Sometimes a few years old. We recently decided to tackle this issue to provide recent versions, and for multiple OSs.

For CI/CD, we have been using buildbots, on top of Travis CI and AppVeyor, to automatically build aircrack-ng on multiple platforms and multiple distros. It happens to every commit done to the master branch in our GitHub repository.

We recently added packages building to the buildbots for a bunch of different distro: Debian, Ubuntu, Mint, SLES, OpenSuse, Fedora, RHEL, CentOS, Amazon Linux and Elementary OS. Stable release packages will be available shortly.

More details will be provided in a separate blog post.

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.