Nowadays, most open source drivers make use of cfg80211 (and sometimes mac80211). There are 2 types of wireless cards:

• FullMac
• SoftMac

Here is a picture on how the different parts, cfg80211/mac80211/nl80211, work together (original StackOverflow post):

Staging drivers are stand alone drivers that are not ready to be merged in the kernel for various reasons such code not ready or driver not stable enough for example.

Linux-wireless wiki is an excellent resource regarding the different drivers.

Those wireless cards have MLME (MAC subLayer Management Entity) handled in hardware usually for power savings reasons (such as smartphones, tablets, SBC and IoT).

With a few exceptions, none of those cards support monitor mode and injection.

SoftMac wireless cards have MLME handled in software with mac80211.

Most of those do support capture and injection (with a few exceptions).

Vendor drivers have their own stack and are often called STA drivers. They are usually limited to Managed mode (client) and sometimes Infrastructure (limited Access Point features) in order to share an Internet connection (tethering). They can be open source or closed source (or a mix of both).

Most of them won't support monitor mode (and injection).

You will need the following to compile drivers:

• Linux kernel headers that match your current running kernel. On openSUSE, the kernel sources also must be installed. Depending on the driver and distribution, you must install the full kernel sources as well.
• The same gcc version that was used to compile your kernel. At least make sure that the first two version numbers or the compiler are the same (e.g. it's OK to use gcc 3.4.6 to compile the driver if the kernel was compiled by gcc 3.4.2). Ignoring this rule will cause Invalid module format errors during module load. That can be checked via /proc/version.
• Always use the latest patches from Kali:
  • kali-wifi-injection.patch
  • wireless-carl9170-Enable-sniffer-mode-promisc-flag-t.patch

Note: if you're using drivers provided by your distribution, they are NOT patched.

General information about patching drivers plus troubleshooting tips can be found in the How To Patch Drivers Tutorial.

Refer to your distribution way of compiling kernels:

• Debian-based distributions
• Ubuntu-based distributions
• OpenSUSE
• RedHat
• Gentoo
• ArchLinux
• Fedora
• CentOS

NOTE: They are not currently maintained due to lack of time.

Linux-backports used to be known as Compat-wireless.

As mentioned previously, the mac80211 drivers quite often support injection out of the box in recent kernels. The mac80211 drivers are improving very rapidly. Sometimes you want to try the latest mac80211 driver without recompiling your entire kernel. This is where Linux-backports comes in. You can now download a package which lets you compile and install the latest advances on the Linux wireless subsystem and get some of the latest drivers without having to recompile your entire kernel. This package adds mac80211, mac80211 drivers, and any new FullMAC driver which has had fairly recent updates.

For full details see the Aircrack-ng Compat-Wireless documentation.

This troubleshooting information applies to Linux only. The individual driver pages may have additional troubleshooting information specific to that driver. This troubleshooting information provides general information which applies to all drivers.

You will need to do a bit of homework first prior to following the troubleshooting tips below. Be sure you know the chipset in your wireless device. Follow this tutorial Tutorial: Is My Wireless Card Compatible? to determine the chipset if you don't already know it. Based on the chipset, determine the proper driver and in turn the kernel modules for it. To do this, you may have to search the internet, the forum and the distribution support.

The first critical step is to ensure that your wireless device is recognized by your system. There are a variety of methods to verify that your system did this successfully. Here are some methods:

• The “dmesg” command can quite often contain detailed messages indicating that the wireless devices was properly detected.
• If the card is an ISA card, you are usually out of luck.
• If the card is a PCI card (miniPCI/miniPCI Express/PCI Express), you need to use the command “lspci” to display the card identification strings.
• If the hardware is a USB dongle, you need to use the command “lsusb” to display the dongle identification strings. In some case, “lsusb” doesn't work (for example if usbfs is not mounted), and you can get the identification strings from the kernel log using “dmesg” (or in /var/log/messages).
• If the card is a Cardbus card (32 bits PCMCIA), and if you are using kernel 2.6.X or kernel 2.4.X with the kernel PCMCIA subsystem, you need to use the command “lspci” to display the card identification strings. If the card is a Cardbus card (32 bits PCMCIA), and if you are using an older kernel with the standalone PCMCIA subsystem, you need to use the command “cardctl ident” display the card identification strings. Try both and see what comes out.
• If the card is a true PCMCIA card (16 bits), and if you are using kernel 2.6.14 or later, you need to use the command “pccardctl ident” to display the card identification strings. If the card is a true PCMCIA card (16 bits), and if you are using an older kernel, you need to use the command “cardctl ident” display the card identification strings. Note that cardmgr will also write some identification strings in the message logs (/var/log/daemon.log) that may be different from the real card identification strings. Usually 16bit PCMCIA cards can be easily identified by the sticker on the bottom of the card with tick boxes or information indicating its a 5V card.

Needless to say, if your wireless device is not detected by your system, you will have to investigate and correct the problem.

Start by running “modprobe <kernel module name>”.

Run the “iwconfig” command and look for wireless devices. Based on the driver, look for an appropriately named interface such as wlan0, wlsp0, etc. The presence indicates that at least the driver is loaded. The absence likely means it did not. This at least gives you a starting point on the problem solving.

Run the “dmesg” command and look for errors relating to your wireless device. At a minimum there should be some messages relating to your device loading and the module initializing it. If there are no messages or errors, you will have to investigate and correct the problem.

Two common issues are:

* “unknown symbol”. * Missing firmware

Some wireless cards require a firmware to work.

The message is very clearly detailed in dmesg, it will tell what filename is missing and where it is expecting it. In some cases, the driver can fall back and try previous version of the firmware.

Files can be manually added to fix the issue but most of the time, firmwares can be found in a package (such as firmware-linux or firmware-linux-nonfree).

When loading the driver kernel module you get a “unknown symbol” error message for one more field names. Sometimes you will see this in the dmesg output as well. This is caused by module you are loading not being matching the kernel version you are running.

First, determine which kernel you are running with “uname -r”. Then use your package manager to determine if you have kernels, kernel headers or kernel development packages that are older.

If you use the RPM package manager then “rpm -qa | grep kernel”. So if you get something like:

kernel-tools-libs-3.10.0-514.2.2.el7.x86_64
kernel-headers-3.10.0-514.2.2.el7.x86_64
kernel-3.10.0-514.2.2.el7.x86_64
kernel-3.10.0-327.13.1.el7.x86_64
kernel-devel-3.10.0-327.el7.x86_64
kernel-devel-3.10.0-514.2.2.el7.x86_64
kernel-devel-3.10.0-327.18.2.el7.x86_64
kernel-tools-3.10.0-514.2.2.el7.x86_64
kernel-devel-3.10.0-327.13.1.el7.x86_64
kernel-3.10.0-327.18.2.el7.x86_64
kernel-3.10.0-327.el7.x86_64

In the example above, there are kernel headers and a kernel development package that match the kernel we are running. If you are missing them, the use yum or equivalent on your distribution to install them such as:

 yum -y install kernel-headers
 yum -y install kernel-devel

Lets assume that “uname -r” returned “3.10.0-514.2.2.el7.x86_64” then all the 3.10.0-327 ones are old and need to be removed. So you remove all the old ones:

 rpm -e kernel-3.10.0-327.13.1.el7.x86_64
 rpm -e kernel-devel-3.10.0-327.el7.x86_64
 rpm -e kernel-devel-3.10.0-327.18.2.el7.x86_64
 rpm -e kernel-devel-3.10.0-327.13.1.el7.x86_64
 rpm -e kernel-3.10.0-327.18.2.el7.x86_64
 rpm -e kernel-3.10.0-327.el7.x86_64

Also change to “/lib/modules” and do a directory listing and remove any directory referring to old kernel versions.

Once you are finished, you can do ““rpm -qa | grep kernel” and confirm everything looks good. At this point, recompile your wireless drivers and reboot the system.

Run the “lsmod” command can be used to see the loaded modules. Confirm that the kernel module for your wireless device is actually loaded. If it is not loaded, you will have to investigate and correct the problem.

Sometimes other modules conflict with the one you are trying to run. See blacklisting below. Additionally, conflicting modules can be moved out of the module tree. If you do this, run “depmod -ae” afterwards.

Run “modinfo <kernel module name>”. This will confirm the module is actually in the modules tree. As well, confirm it is the correct version. Do a “ls -l <file location per modinfo>” and confirm the date matches when you compiled it. It is not uncommon that you are not running the correct module version.

Some laptops have a BIOS setting and/or a physical switch to enable/disable internal wireless cards. Make sure that these are are all “turned on” so that your wireless card is operational.

This can be verified in userspace using rfkill tool:

To list wireless devices and their status:

rfkill list all

A hard block refers to the physical/BIOS switch. The soft block is a software block to disable wireless usually done by network managers.

In order to disable a soft block, the following command will enable wireless functions of all wireless cards on the system:

rfkill unblock all

Notes:

1. A specific wireless interface can be unblocked.
2. For obvious reasons, only a soft block can be disabled.

Two solutions are available for Windows. Currently, only Airpcap is supported with Aircrack-ng 0.9.X

Airpcap is a hardware device that supports monitor mode and injection.

NPcap is a packet sniffing library for Windows. It is based on WinPcap/Libpcap improved with NDIS 6 and LWF.

Github repository and downloads can be found here.

Aircrack-ng does not support NPcap yet. It will support it in the near future.

Monitor mode support is fairly limited in *BSD distributions. FreeBSD has support for capture and injection with a few drivers.

Among all *BSD, FreeBSD has the best support.

Documentation on how to put wireless cards in monitor mode (and requirements to load the drivers) is explained in the man pages of each driver:

• urtwn, for some Realtek USB
• ath for Atheros.

More cards/drivers are supported but a lot of them are not produced anymore

When installing a recent version version of Aircrack-ng, a dedicated airmon-ng will be installed and it will take care of putting card in and out of monitor mode.

• Previous version of this page can be found here.
• Discussion about current state of drivers, chipset and other WiFi-related topics