Deauthenticated after testing 1 PIN

[GoogleCodeExporter]

I am using latest SVN code
I was able to restore some PINs with this excellent tool so it works really 
well.

however there is this one AP that I associate to with a valid spoofed MAC 
address and after testing 1 PIN it immediately kicks me out

any idea why this is happening and how to overcome this problem?

attached pcaps show relevant data

reaver -i wlan0 -b MAC_ADDRESS_HERE -vvv

[+] Switching wlan0 to channel 11
[+] Waiting for beacon from MAC_ADDRESS_HERE
[+] Switching wlan0 to channel 11
[+] Associated with MAC_ADDRESS_HERE (ESSID: ESSID_ADDRESS_HERE)
[+] Trying pin 29833948
[!] WARNING: Failed to associate with MAC_ADDRESS_HERE (ESSID: 
ESSID_ADDRESS_HERE)
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Trying pin 29833948
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[+] Trying pin 29833948

running it with -E option changes output a bit but

[+] Switching wlan0 to channel 11
[+] Waiting for beacon from MAC_ADDRESS_HERE
[+] Switching wlan0 to channel 11
[+] Associated with MAC_ADDRESS_HERE (ESSID: @lien)
[+] Trying pin 95548579
[!] WARNING: Failed to associate with MAC_ADDRESS_HERE (ESSID: 
ESSID_ADDRESS_HERE)
[!] WARNING: Failed to associate with MAC_ADDRESS_HERE (ESSID: 
ESSID_ADDRESS_HERE)
[!] WARNING: Failed to associate with MAC_ADDRESS_HERE (ESSID: 
ESSID_ADDRESS_HERE)
[!] WARNING: Failed to associate with MAC_ADDRESS_HERE (ESSID: 
ESSID_ADDRESS_HERE)
[!] WARNING: Failed to associate with MAC_ADDRESS_HERE (ESSID: 
ESSID_ADDRESS_HERE)
[!] WARNING: Failed to associate with MAC_ADDRESS_HERE (ESSID: 
ESSID_ADDRESS_HERE)
[!] WARNING: Failed to associate with MAC_ADDRESS_HERE (ESSID: 
ESSID_ADDRESS_HERE)

any ideas?

Original issue reported on code.google.com by jcdento...@gmail.com on 4 Jan 2012 at 4:30

• Merged into: #99

Attachments:

• @lien__deauth.pcap
• @liendeauth+E.pcap

[GoogleCodeExporter]

It looks like these pcaps were mis-labeled? In the __deauth.pcap file it looks 
like you're having a lot of issues during the association process. In the 
__deauth__+E.pcap, it looks like the AP isn't seeing many of the WPS messages 
that Reaver is sending. 

The RSSI for @lien AP is -60dbm. Depending on the interference at the AP's 
location and the sensitivity and selectivity of the AP's receiver, you may need 
to get closer or use a directional antenna to boost your signal. If you can, 
try to get a better signal from the AP, or try a different, stronger, AP and 
see if you get the same issues.

Original comment by cheff...@tacnetsol.com on 4 Jan 2012 at 5:20

[GoogleCodeExporter]

well the signal is pretty strong (I recovered passwords even at -75 with ease)
I am using 500mW alfa based on RTL8187L

I can easily associate with aireplay-ng
there are lot of beacons since I was a tad lay filtering them out, I just 
selected traffic based on MAC addresses.

if you search for Deauth packets in wireshark, doesn't it say something useful?

by the way, these captures were taken in 1-2 minute time window after each 
other and neither my WiFi card nor AP moved a single bit.
not much interference either.

is there something that I can do to test if it is something that reaver is 
doing that gets me kicked out or if it is due to other factors?

Original comment by jcdento...@gmail.com on 4 Jan 2012 at 5:26

[GoogleCodeExporter]

Well I do see that you successfully associate to the AP on a few occasions, 
which is why Reaver then starts doing pin attempts, so the AP is letting you 
associate at least.

There is a bug in Reaver's association that with some APs causes the AP to 
deauth Reaver, but in this case I don't see any deauth packets from the AP to 
Reaver, they are all from Reaver to the AP (expected behavior). 

Have you used MAC spoofing when testing other APs? Have you tried testing 
against this AP without spoofing the MAC address? I have had issues before with 
MAC spoofing.

I could be wrong of course, but this looks very much like a connectivity 
problem. Even if you can see traffic from the AP fine and you have tested other 
APs with lower signal levels, that doesn't mean that the current AP can see 
your traffic as easily.

Original comment by cheff...@tacnetsol.com on 4 Jan 2012 at 5:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I tested injection with aireplay-ng and it works well

root@bt:~# aireplay-ng -9 -e @lien wlan0
10:39:53  Waiting for beacon frame (ESSID: @lien) on channel 11
Found BSSID "00:23:69:48:5D:CE" to given ESSID "@lien".
10:39:53  Trying broadcast probe requests...
10:39:53  Injection is working!
10:39:55  Found 1 AP 

10:39:55  Trying directed probe requests...
10:39:55  00:23:69:48:5D:CE - channel: 11 - '@lien'
10:39:57  Ping (min/avg/max): 3.375ms/70.240ms/98.126ms Power: -58.47
10:39:57  30/30: 100%

is there anything else to confirm or disprove that it is signal problem or code 
problem

thanks again very much in advance

Original comment by jcdento...@gmail.com on 5 Jan 2012 at 9:44

Attachments:

• @lien__aireplay_injection.pcap

[GoogleCodeExporter]

I tested injection with aireplay-ng again and it again gave me 100% success

in the attached *.pcap files you can see the messages being exchanged
as you can see I see bidirectional communication so I believe that I can rule 
out insufficient signal strength.

do these captures reveal anything significant to you?

thanks again

Original comment by jcdento...@gmail.com on 5 Jan 2012 at 4:10

Attachments:

• @lien__.pcap
• @lien__-S.pcap
• @lien__-w.pcap
• @lien__-n.pcap

[GoogleCodeExporter]

Hmmm...are you still spoofing your MAC address?

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 5:51

[GoogleCodeExporter]

I am setting it the same way as aireplay-ng is doing
ifconfig INTERFACE hw ether MAC_ADDRESS
I also tried --mac=XX:XX:XX:XX switch in reaver

Original comment by jcdento...@gmail.com on 5 Jan 2012 at 5:55

[GoogleCodeExporter]

Yes, but have you tried not spoofing your MAC address at all?

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 6:23

[GoogleCodeExporter]

I tried,
it did not work but I cannot remember the exact output it generated

will try today in an hour or so and post the results.
do those pcaps tell you anything valuable?

Original comment by jcdento...@gmail.com on 5 Jan 2012 at 6:25

[GoogleCodeExporter]

Only that Reaver and the AP either aren't seeing each other's traffic, or they 
don't think the traffic is valid.

You can see in the first pcap that the AP doesn't appear to see Reaver's 
identity response packets, as the AP keeps sending identity requests. Finally 
the AP seems to see the identity response and sends an M1 packet, but then 
Reaver doesn't seem to see the M1 as the AP has to repeat it many times before 
Reaver responds with an M2 (which doesn't make sense since wireshark could see 
the packets). Likewise, the AP then doesn't appear to see the M2 messages, and 
it goes on and on like that.

One thing that is odd is that on the AP's M1 packet, it specifies an unknown 
configuration error (code 512). This could point to a bug in the AP's code; it 
is also probably why Reaver starts sending M2D packets. Maybe if Reaver ignores 
the error it will complete the transaction, but that still doesn't explain the 
apparent communication problems.

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 6:45

[GoogleCodeExporter]

I changed the debug status in Reaver to show everything in r67. Pull this rev 
down, re-build, run it, and post the output please (it will be a lot, probably 
best to put it in a file).

Original comment by cheff...@tacnetsol.com on 5 Jan 2012 at 7:24

[GoogleCodeExporter]

thanks,
I tested it without spoofing MAC address --> there is MAC filter applied so I 
cannot associate.

attached is output and pcap.
I ran it with spoofed mac address since without doing so it did not do anything

thanks for your time

Original comment by jcdento...@gmail.com on 5 Jan 2012 at 8:08

Attachments:

• @lien___debug.txt
• @lien__debug.pcap
• @lien__debux.txt

[GoogleCodeExporter]

MAC filtering, boo. :P

It looks like Reaver is just never seeing the M3 message from the AP, very 
strange. Is there anything that you did differently between this AP and the 
ones that you tested successfully? 

Original comment by cheff...@tacnetsol.com on 6 Jan 2012 at 12:25

[GoogleCodeExporter]

well apparently MAC filtering.
the interesting thing is that after I set MAC address with ifconfig wlan0 hw 
ether command the output is the same
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message
[!] WARNING: Last message not processed properly, reverting state to previous 
message
[!] WARNING: Out of order packet received, re-trasmitting last message

for this AP and for APs previously cracked and proven to be working
e.g. even the ones that worked and have no MAC filtering fail to test more than 
a single PIN

so to sum it up: when MAC is spoofed using ifconfig even previously working 
ones fail in the same way as @lien does

could it be that this Linksys WRT160N v2 is somewhat similar to my WRT54g2 v1 i 
ticket 8 (http://code.google.com/p/reaver-wps/issues/detail?id=8) Comment #3?

Apparently that WRT54g2 does not use MAC filtering but none the less I cannot 
test a single pin against it (you said it prematurely NACKs the session)

Original comment by jcdento...@gmail.com on 6 Jan 2012 at 12:37

[GoogleCodeExporter]

If they work fine without MAC spoofing but don't work with MAC spoofing, then 
it sounds like Reaver isn't handling MAC spoofing properly, which is a separate 
problem from the WRT54G2 (not sure why the WRT54G2 doesn't work, I know others 
have run Reaver successfully against that model, but I don't know which 
hardware/firmware versions they were using).

Original comment by cheff...@tacnetsol.com on 6 Jan 2012 at 12:56

[GoogleCodeExporter]

well then maybe the name of the ticket should be changed to something about 
correctly handling spoofed MAC address.

I tested this on an already proven to work AP and captured the results with r67

without specifying MAC address in any way, it works just fine
the AP does not use MAC filtering so any MAC of any WiFi card that I have just 
works

on the other hand, when I specify MAC address either via --mac= command or via 
ifconfig hw ether command, it does not.

output looks identical to me (out-of-order packets)

is there anything valuable inside those captures and debug outputs?

Thank you very much

Original comment by jcdento...@gmail.com on 6 Jan 2012 at 8:15

Attachments:

• without_spoofed_MAC.pcap
• without_spoofed_MAC.txt
• with_spoofed_MAC--ifconfig.pcap
• with_spoofed_MAC--ifconfig.txt
• with_spoofed_MAC--mac.pcap
• with_spoofed_MAC--mac.txt

[GoogleCodeExporter]

I get the same type of issue.  Using Backtrack 5R1 in VirtualBox with alpha 
AWUS036H rtl8187 against my D-Link DIR-628.

With no other changes in the setup, if I mac spoof using ifconfig wlan0 hw 
ether ... then I get the out of order warnings.  If I do not mac spoof at all 
then it works fine.  In both cases I'm using the simplest version of the reaver 
command "-i mon0 -vv -b ...".

Original comment by TheShort...@gmail.com on 6 Jan 2012 at 2:40

[GoogleCodeExporter]

I opened a new issue with a more descriptive title, now that we know what the 
underlying problem is. Merging this issue into the new one.

Original comment by cheff...@tacnetsol.com on 6 Jan 2012 at 4:42

• Changed state: Duplicate