This is an old revision of the document!
Aireplay-ng is used to inject frames.
The primary function is to generate traffic for the later use in aircrack-ng for cracking the WEP and WPA-PSK keys. There are different attacks which can cause deauthentications for the purpose of capturing WPA handshake data, fake authentications, Interactive packet replay, hand-crafted ARP request injection and ARP-request reinjection. With the packetforge-ng tool it's possible to create arbitrary frames.
Most drivers needs to be patched to be able to inject, don't forget to read Installing drivers.
It currently implements multiple different attacks:
This section provides a general overview. Not all options apply to all attacks. See the details of the sepcific attack for the relevant details.
aireplay-ng <options> <replay interface>
For all the attacks except deauthentication and fake authentication, you may use the following filters to limit which packets will be presented to the particular attack. The most commonly used filter option is the “-b” to select a specific access point. For typical usage, the “-b” is the only one you use.
When replaying (injecting) packets, the following options apply. Keep in mind that not every option is relevant for every attack. The specific attack documention provides examples of the relevant options.
The attacks can obtain packets to replay from two sources. The first being a live flow of packets from your wireless card. The second being from a pcap file. Standard Pcap format (Packet CAPture, associated with the libpcap library http://www.tcpdump.org), is recognized by most commercial and open-source traffic capture and analysis tools. Reading from a file is an often overlooked feature of aireplay-ng. This allows you to read packets from other capture sessions. Keep in mind that various attacks generate pcap files for easy reuse.
This is how you specify which mode (attack) the program will operate in. Depending on the mode, not all options above are applicable.
Attack modes (Numbers can still be used):
Here are the differences between the fragmentation and chopchop attacks
Optimizing injection speed is more art than science. First, try using the tools “as is”. You can try using the “-x” parameter to vary the injection speed. Surprisingly, lowering this value can sometimes increase your overall rate.
You can try playing with the transmission rate. IE “iwconfig wlan0 rate 11M”. Depending on the driver and how you started the card in monitor mode, it is typically 1 or 11MBit by default. If you are close enough set it up to a higher value, like 54M, this way you'll get more packets per second. If you are too far away and the packets don't travel that far, try to lowering it to (for example) 1M.
These items apply to all modes of aireplay-ng.
Ensure you are using the correct monitor mode interface. “iwconfig” will show the wireless interfaces and their state. For the mac80211 drivers, the monitor mode interface is typically “mon0”. For ieee80211 madwifi-ng drivers, it is typically “ath0”. For other drivers, the interface name may vary.
Make sure there are no other VAPs running. There can be issues when creating a new VAP in monitor mode and there was an existing VAP in managed mode.
You should first stop ath0 then start wifi0:
airmon-ng stop ath0 airmon-ng start wifi0
wlanconfig ath0 destroy wlanconfig ath create wlandev wifi0 wlanmode monitor
You enter the command and the command appears to hang and there is no output.
This is typically caused by your wireless card being on a different channel then the access point. Another potential cause of this problem is when you are using an old version of firmware on prism2 chipset. Be sure you are running firmware 1.7.4 or above to resolve this. See Prism card for more details. Firmware upgrade instruction can be found here.
As well, if you have another instance of aireplay-ng running in background mode, this can cause the second to hang if the options conflict.
See this thread: Aireplay freezes when injecting
Or see this thread: Commenting out RTC
Also check the previous entries.
When using a broadcom chipset and related driver you get something similar to:
write failed: Cannot allocate memory wi_write(): Illegal seek
This is due to a bug in the original bcm43xx patch. Use SuD's modified patch to fix this. Alternatively, you can try using the b43 driver instead of bcm43xx. (B43 requires aireplay-ng 1.0-beta2 or newer; 1.0 rc1 or svn is recommended.)
Symptoms: The injection works but very slowly, at around 30 packets per second (pps). Whenever you start injecting packets, you get the following or similar kernel message:
“rtc: lost some interrupts at 1024Hz”
This message is then repeated continuously. There are a couple of workarounds. The first workaround is to start another instance of aireplay, then injection would increase to around 300 pps. The second workaround is to:
rmmod rtc modprobe genrtc
or if you have rtc-cmos enabled in your kernel:
rmmod rtc modprobe rtc-cmos
There is no solution at this point in time, just the workarounds. See this forum thread.
Being too close to the AP can dramatically reduce the injection rate. This is caused by packet corruption and/or overloading the the AP. See this thread for an example of the impact of being too close to the AP.
This is caused by having two or more instances of aireplay-ng running at the same time. The program will still work but the timing will be less accurate.
After entering an aireplay-ng command similar to:
aireplay-ng -1 0 -e horcer -a 00:50:18:4C:A5:02 -h 00:13:A7:12:3C:5B ath0
You get a message similar to:
The interface MAC (06:13:F7:12:23:4A) doesn't match the specified MAC (-h). ifconfig ath1 hw ether 00:13:A7:12:3C:5B
This occurs when the source MAC address for injection (specified by -h) is different then your card MAC address. In the case above, the injection MAC of 00:13:A7:12:3C:5B does not match the card MAC of 06:13:F7:12:23:4A. In some cases, but not all, this will cause injection to fail. That is why it gives you this warning. So it is always recommended that your injection MAC match the card MAC address.
Detailed instructions on changing the card MAC address can be found in the FAQ: How do I change my card's MAC address ?.
Many aireplay-ng commands require knowing the SSID. You will sometimes see “<length: ?>” as the SSID on the airodump-ng display. This means the SSID is hidden. The “?” is normally the length of the SSID. For example, if the SSID was “test123” then it would show up as “<length: 7>” where 7 is the number of characters. When the length is 0 or 1, it means the AP does not reveal the actual length and the real length could be any value.
To obtain the hidden SSID there are a few options:
See this FAQ entry
When you enter the command, the system freezes or a line is printed with “Waiting for beacon frame” or “No such BSSID available” and then no further activity occurs.
There are many possible root causes of this problem:
For all of the above, running airodump-ng and the related text file should provide all the information you require identify and correct the problem.
A typical example of this message is: “mon0 is on channel 1, but the AP uses channel 6”
This means something is causing your card to channel hop. Possible reasons is that failed to start airodump-ng locked to a single channel. airodump-ng needs to be started with “-c <channel-number>.
Another reason is that you have processes such as a network manager or wpa_supplicant channel hopping. You must kill off all these processes. See[airmon-ng] for details on checking what is running and how to kill the processes off.
Also make sure that: