Troubleshooting

As a reminder, it doesn't work at all with ndiswrapper.

Possible reasons:

• You are standing too far from the access point.
• There is no traffic on the target wireless network.
• There is some G traffic but you're capturing in B mode.
• Something is wrong with your card (firmware problem ?)
• By the way, beacons are just unencrypted announcement packets. They're totally useless for WEP cracking.

As a reminder, you can't inject with a Hermes, Aironet, SiS, non-USB Marvell or some Broadcom chipset because of firmware and/or driver limitations.
Note: You can't inject with OpenWrt devices (This news is an april fool, see post date). (Possibly AR7-based devices can inject using the acx-mac80211 driver, however that driver has no master mode support, and is not included in the official builds.)

If your chipset supports injection, you can try the following:

• Be closer (but not too much, it will be explained later) to the Access Point.
• Decrease the speed for injection and/or the bitrate with which your card is operating. (iwconfig <interface> rate 1M)
• Your driver may be not patched or not up to date. You should always take the latest CVS/SVN revision if it exist (see Drivers).
• See also previous question.

Possible reasons:

• Out of luck: you must capture more IVs. Usually, 104-bit WEP can be cracked with about one million IVs, but sometimes more IVs are needed.
• If all votes seem equal, or if there are many negative votes, then the capture file is corrupted, or the key is not static (EAP/802.1X in use ?).
• A false positive prevented the key from being found. Try to disable each korek attack (-k 1 .. 17), raise the fudge factor (-f) or try the experimental bruteforce attacks (-x / -y).

Shit happens. Last thing you can try is asking the key to the network owner ;)

First step, make sure you aren't using the orinoco driver. If the interface name is wlan0, then the driver is HostAP or wlan-ng. However if the interface name is eth0 or eth1, then the driver is orinoco and you must disable the driver (on 2.4 kernels, use cardctl ident to know you card identifier, then edit /etc/pcmcia/config, replace orinoco_cs with hostap_cs and restart cardmgr; on 2.6 kernels, add “blacklist orinoco_cs” to /etc/modprobe.d/blacklist).

Also, it can be a firmware problem. Old firmwares have trouble with test mode 0x0A (used by the HostAP / wlan-ng injection patches), so make sure yours is up to date (see Prism2 flashing for instructions). The recommended station firmware version is 1.7.4. If it doesn't work well (kismet or airodump-ng stalls after capturing a couple of packets), try STA 1.5.6 instead (either s1010506.hex for old Prism2 cards, or sf010506.hex for newer ones).

On a side note, test mode 0x0A is somewhat unstable with wlan-ng. If the card seems stuck, you will have to reset it, or use HostAP instead. Injection is currently broken on Prism2 USB devices with wlan-ng.

There are quite a few problems with some versions of the Linux 2.6 branch (especially before 2.6.11 was released) that will cause a kernel panic when injecting with madwifi. Also, on many 2.6 kernels enhanced RTC support is just broken. Thus, is it highly recommended to use either Linux 2.6.11.x or newer.

You have 2 workarounds:

• Change the rate before using airodump-ng
• Restart airodump-ng

Some cards are not recognized by the Windows drivers above, even though they have the correct chipset. In this case, open the hardware manager, select your card, “Update the driver”, select “Install from a specific location”, select “Don't search, I will choose the driver to install”, click “Have disk”, set the path to where the driver has been unzipped, uncheck “Show compatible hardware”, and finally choose the driver.

It was due to the use of madwifi-ng with aircrack and aircrack-ng up to 0.2.1

Problem: The wireless card behaves badly if the signal is too strong. If I'm too close (1-2m) to the access point, I get high quality signal but actual transmission rates drop (down to 5-11Mbps or less). The net result is TCP throughput of about 600KB/s.

This is called antenna and receiver saturation. The signal coming in to the preamplifier is too strong and clips the input of the amplifier, causing signal degradation. This is a normal phenomenon with most 802.11 hardware.

Neither, really. It's a physics problem. The only solution is to either decrease transmission power, use an antenna with a lower gain factor, or move the access point farther away from the station. You should use wired ethernet when you're close to the access point. If you don't want or you don't have a wire, you can also decrease output power of your Access point or your card.

This usually happens because the linux headers don't match your current running kernel. In this situation, grab the kernel sources or just recompile a fresh kernel, install it and reboot. Then, try again compiling the driver. See this HOWTO for more details about kernel compilation.

Both airodump-ng and aireplay-ng sources are Linux-specific.

Double check that your device name is correct and that you haven't forgotten a parameter on the command line. When using linux-wlan-ng driver, be sure to enable the interface first with airmon-ng.

If the .ivs file was generated using pcap2ivs from aircrack (any version) or aircrack-ng (up to 0.2.1). It is corrupted by a bug in those versions. You should upgrade to aircrack-ng 0.3 or more.

You can try to recover part of the information using FixIvs.

Your .ivs file may have been corrupted if you used pcap2ivs. Read previous point.

wpa_supplicant or a network manager may be running and try to get connected to an Access Point. You should stop it before running airodump-ng.

See http://forum.aircrack-ng.org/index.php?topic=901.0