Failure if packets are retransmitted by the AP

[GoogleCodeExporter]

When the AP retransmit the M1, M3 or M5 messages, and one of this 
retransmissions is received after sending the answer (M2, M4 or M6), reaver 
thinks it is an error, and sends an WSC_NACK, terminating the handshake.

I have suffered this, and commenting in exchange.c the "else" part on case M1, 
M3 and M5 of the "switch" around line 100, solved the issue. This way, it does 
not send WSC_NACK when receiving that retransmissions out of time.

I cannot upload a capture here, it says "Issue attachment storage quota 
exceeded", so I have uploaded it to cloudshark.org. You can see it on 
http://www.cloudshark.org/captures/f31b9e1c527f
There are lots of retransmissions (due to not very good signal), some of them 
out of order (M3 received after M4 sent). This capture was done after 
commenting the elses mentioned above.

Original issue reported on code.google.com by a123a654...@gmail.com on 17 Jan 2012 at 4:04

[GoogleCodeExporter]

Yeah, we need to clean out the uploaded attachments here, sorry about that.

Area you only commenting out the else statement, or the entire if-else 
statement? These were added specifically to address other bugs that occurred 
when certain packets were received out of order, so I'll have to do some 
testing before deciding if this should be fixed or if it will cause other 
problems in other situations.

Original comment by cheff...@tacnetsol.com on 17 Jan 2012 at 4:21

• Changed state: Accepted
• Added labels: Priority-Medium
• Removed labels: Priority-Triage

[GoogleCodeExporter]

Only the else part, when it change the tx_type to SEND_WSC_NACK, and activate 
the terminated flag. I did it to ignore those retransmitted packets already 
received.

I have read little of your code, but don't understand why a repeated M1, M3 or 
M5 lead to terminating the handshake, what kind of error could it cause if you 
not do so?

Original comment by a123a654...@gmail.com on 17 Jan 2012 at 8:48

[GoogleCodeExporter]

Removing just the else statements shouldn't cause any errors, but...

In most cases if Reaver's state machine and the AP's state machine get out of 
sync, Reaver has two choices:

1) Let the connection timeout (can take a few seconds or a few minutes)
2) Explicitly terminate the connection and try again

Usually #2 is obviously faster. In your case though, the AP is acting a bit 
strangely. Most APs will send an M1 packet, then wait a few seconds for an M2 
response before re-transmitting the M1 packet. In your case the AP is 
essentially flooding you with M1 packets until it sees an M2, then flooding you 
with M3 packets until it sees an M4, etc, etc. So even though no one is out of 
sync, Reaver sees multiple M1s and assumes that something is wrong.

I will put an option in Reaver to tell it to not NACK repeated packets so that 
situations like this can be handled properly.

Original comment by cheff...@tacnetsol.com on 17 Jan 2012 at 9:19

[GoogleCodeExporter]

Thanks for that option you will do!
If you see the IEEE 802.11 header, the retry flag is active in all the packets 
retransmitted (and sometimes even in the first one), so I think it is being 
retransmitted by the wireless driver, not the WPS software (possibly because it 
doesn't receive the IEEE 802.11 ACK (does a wireless card in monitor mode sends 
ACKs of frames sent to us? even with the MAC spoofed?), but I suppose this is 
out of the scope of this tool). :)

Original comment by a123a654...@gmail.com on 18 Jan 2012 at 12:10

[GoogleCodeExporter]

r106 now has a --no-nacks option which will prevent Reaver from sending NACKs 
when repeated WPS messages are received from the AP. Use of this flag does have 
the potential to cause Reaver to hang indefinitely if no messages are received, 
but in this case I don't think that's an issue. :)

The driver retransmitting packets makes much more sense, I should have looked 
more closely at the headers. I don't think this is a MAC spoofing issue, unless 
maybe it pertains to the card/driver you are using; I've used MAC spoofing 
against several different APs and haven't encountered this behavior before.

Original comment by cheff...@tacnetsol.com on 18 Jan 2012 at 12:52

• Changed state: Fixed