Na razie, aireplay-ng wspiera packet injection tylko na chipsetach Prism2, PrismGT (FullMAC), Atheros, Broadcom (jeśli używasz sterownika b43), RTL8180, RTL8187, Ralink, ACX1xx oraz ZyDAS. Chipsety Hermes, Aironet oraz Marvell nie są wspierane z powodu ograniczeń w firmware bądź samych sterownikach.

Istnieją dwie „rodziny” sterowników - ieee80211 oraz mac80211. Sterowniki mac80211 zaczynają powoli wypierać te oparte na ieee80211. Przeczytaj tą część artykułu aby dowiedzieć się czegoś więcej. Jeśli sterownik oparty na mac80211 jest stabilny i wspiera packet injection bez żadnych problemów, powinien być on tym, którego wybierzesz, ale miej na uwadze, że sterowniki mac80211 są dobrze obsługiwane dopiero w kernelu 2.6.25 oraz nowszych. W wielu przypadkach jednak jedynymi sterownikami, które obsługują packet injection i są stabilne, są te oparte na ieee80211.

Prawie wszystkie sterowniki, które nie są oparte na mac80211 wymagają załatania, by mogły obsługiwać packet injection w trybie monitorowania. Z drugiej strony, sterowniki oparte na mac80211 potrzebują tylko załatania samego jądra mac80211 w celu obsługi ataku fragmentacji.

Pamiętaj, że nie możesz używać sterowników opartych na ieee80211 i mac80211 jednocześnie. Musisz zdecydować się na użycie jednego z nich, a nie dwóch. Jeśli spróbujesz załadować obydwa, jeden z nich nie załaduje się. Musisz więc ciągle podejmować decyzję odnośnie sterownika, którego chcesz używać i dopisywać wersję, której nie chcesz używać do czarnej listy - tj. jeśli w systemie masz zainstalowane obydwie wersje.

Miej także na uwadze, że sterowniki napisane pod mac80211 są ciągle stosunkowo niedojrzałe w porównaniu z tymi napisanymi pod ieee80211. Przygotowanie infrastruktury mac80211 tak, aby działała poprawnie na Twoim systemie wymaga większych umiejętności i obycia z Linuksem. Używanie jej może też narazić Twój system na ewentualne niebezpieczeństwa, jako że korzystasz z oprogramowania „bleeding edge”. Tak więc jeśli nie uważasz, że masz wystarczające umiejętności bądź dużo cierpliwości, stosuj sterowniki ieee80211.

Do kompilacji sterowników potrzebować będziesz następujących narzędzi :

• Nagłówków dla aktualnie zainstalowanego jądra - na openSUSE, potrzebne jest także posiadanie całego źródła jądra.
• gcc w wersji takiej samej, jaka była użyta do kompilacji jądra. Upewnij się chociaż, że pierwsze dwie cyfry w wersji kompilatora są takie same (tj. możesz użyć wersji 3.4.6 do kompilacji sterowników jeśli jądro zostało skompilowane przez wersję 3.4.2). Ignorowanie tej zasady doprowadzi do błędów Invalid module format podczas ich ładowania. Wersję kompilatora użytą do kompilacji jądra możesz sprawdzić przez /proc/version.
• Zawsze używaj najnowszych łatek, które możesz znaleźć tutaj

Uwaga: jeśli używasz sterowników dostarczonych przez Twoją dystrybucję, NIE SĄ one załatane! (jedyne wyjątki to BackTrack bądź inne dystrybucje używane do penetracji sieci)
Ogólne informacje odnośnie łatania jak i propozycje rozwiązywania problemów znajdują się w poradiku odnośnie łatania.

Poniżej znajdują się szczegółowe informacje na temat konkretnych sterowników opartych na ieee80211 :

• acx
• bcm43xx
• HostAP (prism2)
• ipw2200
• ipw3945
• madwifi-old
• madwifi-ng
• prism54
• r8180-sa2400
• r8187
• r8187b
• rt2500
• rt2570
• rt2870
• rt61
• rt73
• wlan-ng (prism2)
• zd1211rw

Aby móc wspierać atak fragmentacji, sterowniki napisane pod mac80211 wymagają, aby załatane było jądro mac80211.

• wskazówki dotyczące łatania jądra mac80211

Powyższy artykuł zawiera też informacje na temat sterowników, których poprawne działanie z aircrack-ng zostało potwierdzone.

Następujące sterowniki mac80211 wymagają dodatkowych łatek w celu umożliwienia pracy w trybie monitorowania bądź przyspieszenia jego działania. (działanie każdej z łatek wyjaśnione jest w nawiasach)

• iwlagn (umożliwienie packet injection w 2.6.24/.25, kiedyś znany jako iwl4965)
• rtl8187 (poprawa szybkości)
• zd1211rw-mac80211 (całkowite wyłączenie filtrowania pakietów w trybie monitorowania)

Uwaga : W przypadku innych sterowników po prostu postępuj zgodnie z zasadami Twojej dystrybucji.

Na systemach Windows aktualnie wspierane jest tylko monitorowanie. „Zwykłe” sterowniki go nie wspierają w ogóle, dlatego konieczne jest zainstalowanie sterowników wildpackets. W przypadku chipsetów Atheros - jeśli Twojego modelu nie ma na liście bądź nie wiesz, który sterownik zastosować, po prostu ściągnij najnowszą wersję.

Mówiąc krócej, wszystkie karty z chipsetem Atheros powinny być obsługiwane. Urządzenia na USB bądź Centrino na pewno nie są.
Na stronie Poradnik : kompatybilność, sterowniki, jaką kartę kupić znajduje się pełna lista obsługiwanych chipsetów.
W wersji 1.0, obsługiwany będzie adapter Airpcap.

• Instalowanie sterowników wildpacket

Informacje dotyczące rozwiązywania problemów znajdujące się tutaj dotyczą tylko Linuksa. Bardziej konkretne informacje mogą się znajdować na stronie konkretnych sterowników. Tutaj znajdują się tylko informacje ogólne, dotyczące wszystkich sterowników.

Zanim zabierzesz się za rozwiązywanie problemów, musisz odrobić zadanie domowe. Po pierwsze, musisz znać chipset swojej karty bezprzewodowej. Jeśli jeszcze go nie znasz, przeczytaj artykuł Poradnik : Czy moja karta bezprzewodowa jest kompatybilna?. Bazując na informacji o chipsecie, dowiedz się który sterownik go obsługuje i - w związku z tym - których modułów jądra potrzebujesz. Aby to osiągnąć, będziesz musiał przeszukać Internet, nasze forum, bądź wsparcie dla Twojej dystrybucji.

Pierwszym koniecznym krokiem jest określenie, czy Twoja karta jest wykrywana przez system. There are a variety of methods to verify that your system did this successfully. Here are some methods:

• komenda „dmesg” całkiem często posiada dużo informacji na temat wykrytej karty i jej chipsetu,
• jeśli Twoja karta używa magistrali ISA, to z reguły nie będziesz w stanie się niczego dowiedzieć
• jeśli Twoja karta używa magistrali PCI, będziesz musiał użyć komendy „lspci -nn” aby uzyskać ciągi identyfikujące urządzenia. W paru przypadkach, na przykład kart opartych na chipsetach Broadcom, wystarcza to do zidentyfikowania chipsetu. Parametr „-nn” powinien spowodować, że wyświetlone zostaną identyfikatory PCI ID. Przykładowy PCI ID dla karty opartej na chipsecie Atheros to „168c:0013”. Gdy już go posiadasz, w Internecie istnieje wiele stron dzięki którym możesz do niego dopasować chipset. Dwie z tych stron to http://pciids.sourceforge.net/ oraz http://www.pcidatabase.com/. Możesz znaleźć inne używając zapytania „PCI ID” w wyszukiwarkach. Komenda ta wyświetla także wymagane moduły kernela i moduły znajdujące się w użyciu - mogą one być także całkiem pomocne przy określaniu chipsetu.
• jeśli Twoja karta używa interfejsu USB, analogicznym narzędziem do powyższego jest „lsusb”. Czasami może on niestety nie działać, na przykład gdy nie jest zamontowany usbfs - w tym przypadku w celu pozyskania ciągów identyfikujących urządzenie użyj komendy „dmesg”.
• jeśli Twoja karta używa interfejsu Cardbus (32-bitowy PCMCIA), a Ty masz zainstalowany stosunkowo nowy kernel (2.4.X lub nowszy) z obsługą podsystemu PCMCIA, możesz użyć komendy „lspci -nn” w celu wyświetlenia ciągów identyfikujących. Jeśli jednak używasz starszego kernela, musisz użyć komendy „cardctl ident” aby wyświetlić ciągi.
• jeśli Twoja karta jest prawdziwą 16-bitową PCMCIA, a Ty używasz kernela nowszego niż 2.6.14, w celu wyświetlenia ciągów identyfikujących możesz użyć komendy „pccardctl ident”. Jeśli używasz starszego kernela, to samo możesz osiągnąć używając komendy „cardctl ident”. Miej na uwadze, że cardmgr wypisuje pewne ciągi identyfikujące do logów, jednak różnią się one od faktycznych ciągów identyfikujących dane urządzenie.

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 ath0, rausb0, 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.

A common problem is that your system has both ieee80211 and mac80211 versions of the drivers. Having wmaster0 typically indicates you are using the new mac80211 drivers. Having wifi0 or eth0 typically means you are using the older (legacy) ieee80211 drivers. Having both wmaster0 and wifi0/eth0 (as well as weird interface names like wlan0_rename) might indicate a udev problem. Based on what which ones you really want, you may have to blacklist or move one or more drivers.

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.

See the next entry of a problem commonly seen: „unknown symbol”.

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-headers-2.6.24.4-64.fc8
 kernel-2.6.24.4-64.fc8
 kernel-devel-2.6.24.4-64.fc8
 kernel-headers-2.6.24.1-15.fc8
 kernel-2.6.24.1-15.fc8
 kernel-devel-2.6.24.1-15.fc8

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 „2.6.24.4-64.fc8” then all the 2.6.24.1-15 ones are old and need to be removed. So you remove all the old ones:

 rpm -e 2.6.24.4-64.fc8
 rpm -e kernel-2.6.24.1-15.fc8
 rpm -e kernel-devel-2.6.24.1-15.fc8

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.

A common problem on newer kernels is that the new mac80211 version of the driver gets loaded instead of the older legacy driver, or vice versa. If that is the case, then you need to blacklist the wrong modules by editing /etc/modprobe.d/blacklist. First, determine the broken module names and add them to the blacklist file as „blacklist <module name>”.

Specifically for madwifi-ng, do a locate or find for ath5k.ko. If ath5k.ko exists then add „blacklist ath5k” to /etc/modprobe.d/blacklist and reboot. Same for the other way around: if you want to load ath5k, but madwifi-ng gets loaded instead, add „blacklist ath_pci” to /etc/modprobe.d/blacklist.

Although it is not very „scientific”, sometimes simply unloading then reloading the driver will get it working. This is done with the rmmod and modprobe commands.

For b43 and b43legacy, it might also be necessary to reload the underlying SSB module. Similarly, rt2x00 and p54 might need reloading of the common modules (p54common, rt2x00lib, rt2x00usb, rt2x00pci). Sometimes (especially with mac80211 drivers), reloading the stack (for example, modules „cfg80211” and „mac80211”) might do the trick.

There is a new wireless stack starting in the mainline kernel since 2.6.22 called mac80211. As newer versions of the kernel get released more and more wireless devices are being supported by it. It has the huge advantage of being included in the kernel itself. The mac80211 stack has features such as software MAC (media access controller), hostapd, WEP, WPA, WME, a „link-layer bridging module,” and a QoS (quality of service) implementation. Of specific interest to aircrack-ng is native monitor mode and injection support.

The legacy drivers use the ieee80211 or net80211 stacks. And quite often there is one stack per wireless device. Depending on the driver, it does not provide native monitor mode or injection support.

So with this as background, here is troubleshooting information for problems that arise when both stacks are installed on a system. There are four classes of problems:

• The mac80211 driver for your wireless device is not stable or the monitor mode / injection functionality is not working well.
• You are using a mac80211 driver, but your aircrack-ng version is too old to support Radiotap.
• You are using the legacy driver for your device and want to switch to the mac80211 driver.
• The old and new modules conflict.

You can tell if you are running the new mac80211 stack based on the kernel version or you likely get an error message similar to:

 airmon-ng start wlan0

 Interface       Chipset         Driver
 
 wlan0                   iwl4965 - [phy0]/usr/sbin/airmon-ng: line 338: /sys/class/ieee80211/phy0/add_iface: Permission denied
                                 mon0: unknown interface: No matching device found
                                 (monitor mode enabled on mon0)

or in aircrack-ng v1.0-rc1 and newer:

 airmon-ng start wlan0

 Interface       Chipset         Driver
 
 wlan0                   iwl4965 - [phy0]
 
 ERROR: Neither the sysfs interface links nor the iw command is available.
 Please download and install iw from http://dl.aircrack-ng.org/iw.tar.bz2

Notice the reference to „phy0” and „mon0”. Read the page mac80211 for a fix for this error. if the error doesn't show up, then the correct output of airmon-ng is like this:

 airmon-ng start wlan0

 Interface       Chipset         Driver
 
 wlan0                   iwl4965 - [phy0]
                                 (monitor mode enabled on mon0)

Another indicator of the mac80211 driver being loaded is if the output from iwconfig includes:

 wmaster0  no wireless extensions. 

Notice the reference to „wmaster0”.

Perhaps the most consistent way of determining the stack type of your drivers is running the command „lsmod | grep mac80211.” If the output includes a line like this:

 mac80211              229108  4 rt2x00usb,b43,rt2x00lib,zd1211rw

then the modules at the end of the line are mac80211 drivers.

If the new mac80211 driver is not working to your satisfaction then you will have to blacklist it and then use the ieee80211 legacy version. The wiki driver section on this page has links to the various drivers.

It is also possible that the new driver is not working because your version of aircrack-ng is too old. Updating to at least 1.0-rc1 often fixes such problems.

If you are using a legacy driver, and want to switch to the mac80211 driver, then you need to blacklist the old driver, and enable the new one. If the names of the old and new in-kernel drivers match (for example, with zd1211rw, which is softmac in 2.6.24 and before, but mac80211 in 2.6.25), then you need to upgrade your wireless subsystem (either by updating the kernel or using compat-wireless-2.6).

If you have conflicts due to running both drivers, then decide which one you want and blacklist the other one.

When using an USB device and you get a message similar to this from dmesg:

 rt73: Firmware loading error
 rt73: Failed to load Firmware.
 rt73: probe of 1-7:1.0 failed with error -71

Note: Although the example shows RT73, this applies to any USB driver.

Here are a few things to check:

• Ensure you have the firmware installed on your system and in the correct location.
• You can try downloading a fresh copy of the driver and installing it again.
• Try connecting your USB device directly to your computer without a cable. Cables can be defective and/or too long. If they are too long then the signal may degrade or there is insufficient power.
• If you have multiple USB devices connected to your computer then remove them all except the wireless device and retry.

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.