Enhancement Request: Intelligent Timeout on Limiting.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Currently if the AP starts to limit the default wait time is 315 seconds.
Or can be set manually to a different value using the -l variable.
2.
3.

What is the expected output? What do you see instead?
Instead of 'fixing' the timeout to 315 seconds why not set it initially to 60 
seconds, then step it up in 60 seconds blocks if the 1st restart shows the AP 
is still limiting.

i.e.

Detected AP rate limiting, waiting 60 seconds before restarting.
Detected AP rate limiting, waiting 120 seconds before restarting.
Detected AP rate limiting, waiting 180 seconds before restarting.

and so on till we get a time that works, then store that value in the session 
file.

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by pinsb...@gmail.com on 5 Jan 2012 at 1:18

[GoogleCodeExporter]

Good idea; added and checked in (r64).

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

• Changed state: Fixed
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

The new feature is more like a regression to me.  With a particular AP I had 5 
consecutive 60 second delays (=300 seconds) with  "-l 60" at regular intervals 
(AP enforcing lockdown).  Now (r64), with the same AP, even without the "-l 60" 
option (maybe reaver saved the 60 value in the session file as I did run it 
once (r64) with the "-l 60" option), reaver waits consecutively for 60 + 120 + 
180 seconds (=360 seconds) on each lockdown, which is 60 longer than it 
_really_ had to.  I have to manually stop/restart reaver in the middle of the 
last wait (180) and it resumes accepting PINs no problem.

So, I rather have the old behavior, which worked best just giving a small value 
on the -l option and let it retry the smaller timeout on each lockdown 
iteration.  FYI.  Thanks!

Original comment by vsil...@gmail.com on 5 Jan 2012 at 4:41

[GoogleCodeExporter]

On the next AP lockdown iteration it is actually doing 180 + 240 (second) waits 
which is definitely not optimum (=420 seconds) since I know, for a fact, that 
this AP only needs no more than 5 + 60 (=300 seconds).  Can we get the old 
behavior back?  Thanks!

Original comment by vsil...@gmail.com on 5 Jan 2012 at 4:49

[GoogleCodeExporter]

Old behavior back by popular demand. :)  My code needs to be smarter, and allow 
for manual overrides.

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

[GoogleCodeExporter]

Gah, I must have been tired last night.

This feature is really unnecessary. Reaver will not do anything until the AP is 
unlocked (unless --ignore-locks has been specified of course). The timeout 
period is how long Reaver waits to check again to see if the AP is unlocked, 
but if the AP is still locked it will just sit in a loop sleeping and checking 
until the AP is unlocked. So really, having an adaptive timeout only changes 
how often the warning gets printed.

If you want to make sure that the least amount of time is spent waiting for the 
AP to unlock, manually specify the timeout period as 1 second. This will result 
in a lot of warning messages, but Reaver will check every second to see if the 
AP has unlocked itself, and when it has, the attack will continue.

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

[GoogleCodeExporter]

Does the AP come out of locked mode if it's constantly being re-hit?

Or does Reaver do a listen to locked status BEFORE it resends a PIN when it's 
coming out of unlocked mode?

Original comment by pinsb...@gmail.com on 5 Jan 2012 at 7:15

[GoogleCodeExporter]

The AP will usually come out of locked mode if pins are constantly being tried 
during the locked period, though this may not always be the case.

Reaver listens to see if the AP is unlocked before trying any more pins.

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

[GoogleCodeExporter]

OK Thanks, in that case it makes sense.

Obviously my original concern was that the AP was getting hit with a new pin 
attempt while locked, detected the new hit and restarting the lock timer.

If Reaver is listening before the re-hit then that makes more sense.

While writing this.....

Surely then if Reaver is listening before resending the next PIN attempt after 
a lockup surely the most logical process flow (and output) would be....

AP Goes into lock mode.

Reaver states something like....

AP locked, listening till unlocked........

and then a timestamp and repeat message say every 300 seconds (to ensure Reaver 
hasn't hung).

I think this would make it clearer regarding what Reaver is doing?

Original comment by pinsb...@gmail.com on 5 Jan 2012 at 8:16

[GoogleCodeExporter]

Hello Developer hello Fellas question to Developer is it possible to make and 
run together mdk3 with reaver to bypass the AP lock after 60 ... maybe i am 
wrong thanks

Original comment by Dardan.S...@gmail.com on 11 Apr 2012 at 10:46