FullMac

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

SoftMac wireless cards have MLME handled in software with mac80211.

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

Vendor drivers

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

Driver compilation

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.

Compat-Wireless / Linux backports

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.

Troubleshooting

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.

Hardware Verification

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.

Modprobe

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

View iwconfig output

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.

View dmesg output

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

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

"unknown symbol" error

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:

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:

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.

View lsmod output

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.

View modinfo output

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.

Laptop Specific

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:

A specific wireless interface can be unblocked.

For obvious reasons, only a soft block can be disabled.

Windows

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

Airpcap

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

NPcap

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