Infinite re-trying loop

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run reaver: "reaver -i mon0 -b xx:xx:xx:xx:xx:xx -vv -c 1"
2. wait until message appears "[!] WARNING: Detected AP rate limiting, waiting 
315 seconds before re-trying"

What is the expected output? What do you see instead?
After waiting 315 seconds the attack should resume. Instead reaver is waiting 
another 315 seconds; over and over again.

What version of the product are you using? On what operating system?
I am using Backtrack 5 R1 and reaver r22, b43 driver

Please provide any additional information below.
The attack works until 0.25% is reached,
[+] 0.25% complete @ 3 seconds/attempt
then reaver waits forever to resume,
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
even though I am able to cancel the attack, immediately restart it and then it 
works again until ca. 0.25% is reached.

Router is "Netgear WNDR3400".

Original issue reported on code.google.com by test_ran...@hotmail.de on 30 Dec 2011 at 4:06

[GoogleCodeExporter]

I can confirm. I just created a duplicate of this issue without seeing this one.

Original comment by rtstanif...@gmail.com on 30 Dec 2011 at 4:11

[GoogleCodeExporter]

Some netgears will lock WPS registrar attempts after X failed attempts (seems 
to vary). This locked state is reported in the AP's beacon packets as part of 
the WPS information element. If reaver sees that the AP is reporting that it 
has locked itself, it will give you this warning and wait 315 seconds before 
re-trying.

You can reduce the sleep period using --lock-delay or disable it altogether 
with --ignore-locks.

Original comment by cheff...@tacnetsol.com on 30 Dec 2011 at 4:16

[GoogleCodeExporter]

The problem is though that Reaver isn't detecting when the router has removed 
the rate limiting. This is evident in the fact that it works fine if you 
restart the attack.

Original comment by rtstanif...@gmail.com on 30 Dec 2011 at 4:33

[GoogleCodeExporter]

Understood. :)  Until a fix is out though, you should be able to use those 
options to work around the issue.

Original comment by cheff...@tacnetsol.com on 30 Dec 2011 at 4:43

[GoogleCodeExporter]

Sorry, I thought you didn't understand. :P

Original comment by rtstanif...@gmail.com on 30 Dec 2011 at 4:46

[GoogleCodeExporter]

Using "--ignore-locks" gives me:

[+] 0.27% complete @ 3 seconds/attempt
[+] Trying pin 97905882
[!] WARNING: Receive timeout occurred
[+] Trying pin 97905882
......
[!] WARNING: Receive timeout occurred
[+] 0.27% complete @ 4 seconds/attempt
[+] Trying pin 97905882
[!] WARNING: Receive timeout occurred
[!] WARNING: 10 failed connections in a row

This means the router in fact locks WPS registrar attempts for some time but by 
extending the sleep period to 601 secods with "--lock-delay 601" I get that:

...
[+] 0.24% complete @ 2 seconds/attempt
[+] Trying pin 10062999
[+] Trying pin 59722991
[+] Trying pin 46372994
[+] Trying pin 36452996
[!] WARNING: Detected AP rate limiting, waiting 601 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 601 seconds before re-trying

600 seconds should be more that enough time to wait, shouldn't it ?
I am still able to just restart the attack successfully (sometimes I have to 
wait like one minute until it works again).

Original comment by test_ran...@hotmail.de on 30 Dec 2011 at 4:54

[GoogleCodeExporter]

I don't think that extending the sleep period right now will help since reaver 
isn't seeing the switch back to an unlocked state.

Original comment by cheff...@tacnetsol.com on 30 Dec 2011 at 5:00

[GoogleCodeExporter]

I just wanted to say that if reaver was able to see the switch back 600 seconds 
should be enough; now it is clear what exactly the problem is, I suppose :)

Original comment by test_ran...@hotmail.de on 30 Dec 2011 at 5:05

[GoogleCodeExporter]

Same issue here... i wonder what 's the meaning of this attack if the target 
router is locking you out.. after 4-5 tries i have the same issue.. :(((

Original comment by tsakirt...@gmail.com on 31 Dec 2011 at 9:59

[GoogleCodeExporter]

Same thing here, also with a Netgear router. Reaver stops at 0.25% and waits 
infinitely.
Ubuntu 10.04 64-bit iwlagn driver.

Original comment by przemekk...@gmail.com on 31 Dec 2011 at 10:45

[GoogleCodeExporter]

i forgot to say i use backtrack 5 gnome 32

Original comment by tsakirt...@gmail.com on 31 Dec 2011 at 1:30

[GoogleCodeExporter]

Netgears are known to implement lockouts. Some only lock you out for 5 minutes, 
some may lock you out longer, or even indefinitely. I'll try and track down the 
issue with Reaver not detecting a unlocked AP when I get back from holiday.

Original comment by cheff...@tacnetsol.com on 31 Dec 2011 at 1:33

[GoogleCodeExporter]

I had the same problem, it would lock me out for 5 minutes but it never would 
resume after the 315 second interval. I used the -L flag so it disables the 
lock delay as suggested above and now it works great. Granted it will keep 
trying the same key with the WARNING: Receive timeout occurred, but will 
continue when the router lifts the 5 minute ban. This is probably a good way to 
get perma banned on some routers, but it seems to be a working solution for 
this one.

Original comment by d0...@d0zs.tk on 1 Jan 2012 at 6:13

[GoogleCodeExporter]

This workaround actually worked for me after waiting long enough, too. Looks 
like I canceled the attack too soon the first time I tested that.

Original comment by test_ran...@hotmail.de on 1 Jan 2012 at 8:45

[GoogleCodeExporter]

Bug reproduced, work in progress.

Original comment by cheff...@tacnetsol.com on 3 Jan 2012 at 4:53

• Changed state: Started

[GoogleCodeExporter]

Bug was that old packets were being buffered during the sleep and then 
processed after waking up. Thus, old packets (marked as locked) were 
interpreted as new packets. Should be fixed now.

Original comment by cheff...@tacnetsol.com on 3 Jan 2012 at 6:40

[GoogleCodeExporter]

Fixed, thank you!

It probably doesn't belong here but after the timeout it looks like the 
speed-calculation is incorrect as I am still attacking at the same speed.

[+] 0.22% complete @ 2012-01-03 20:19:30 (3 seconds/attempt)
[+] 0.26% complete @ 2012-01-03 20:19:45 (3 seconds/attempt)
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[+] 0.31% complete @ 2012-01-03 20:25:15 (12 seconds/attempt)
[+] 0.35% complete @ 2012-01-03 20:25:29 (11 seconds/attempt)
[+] 0.40% complete @ 2012-01-03 20:25:44 (10 seconds/attempt)

Original comment by test_ran...@hotmail.de on 3 Jan 2012 at 7:31

[GoogleCodeExporter]

Awesome, glad that fixed it.

The seconds/attempt is an average based on the entire time that Reaver has been 
running. So since you had to sleep for 5 minutes due to the lockout, your 
average seconds/attempt obviously went up too.

Original comment by cheff...@tacnetsol.com on 3 Jan 2012 at 7:40

• Changed state: Fixed

[GoogleCodeExporter]

Excellent work, thanks cheff for the quick fix.

Original comment by d0...@d0zs.tk on 4 Jan 2012 at 11:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I believe I have the same issue as test_ran. It will constantly tell me 
Detected AP rate limiting until I cancel it and reload. Then it goes smoothly 
for about 10 minutes then back again. 

Router: Netgear WNDR3400

[+] 7.11% complete @ 2012-01-10 19:31:43 (3 seconds/attempt)
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
[!] WARNING: Detected AP rate limiting, waiting 315 seconds before re-trying
^C
[+] Session saved.
root@bt:~# reaver -i mon0 -b **:**:**:**:**:** -vv -c 1

Reaver v1.3 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 
<cheffner@tacnetsol.com>

[+] Switching mon0 to channel 1
[?] Restore previous session? [n/Y] y
[+] Restored previous session
[+] Waiting for beacon from **:**:**:**:**:**
[+] Switching mon0 to channel 1
[+] Associated with **:**:**:**:**:** (ESSID: *****)
[+] Trying pin 47071520
[+] Trying pin 42821526
[+] Trying pin 78151529

Please help.

Original comment by Garyv...@gmail.com on 11 Jan 2012 at 12:53

[GoogleCodeExporter]

Use the latest code from subversion.

Original comment by cheff...@tacnetsol.com on 11 Jan 2012 at 12:59

[GoogleCodeExporter]

Lets say I don't exactly know my way around linux.... Sorry.

Original comment by Garyv...@gmail.com on 11 Jan 2012 at 1:03

[GoogleCodeExporter]

Ah, ok, no worries. :)

You'll need to install subversion on your Linux machine if it is not already 
installed. You should be able to do this with your distro's package manager 
pretty easily ('apt-get install subversion' on debian/ubuntu for example).

Then you can check out the latest subversion code with:

$ svn checkout http://reaver-wps.googlecode.com/svn/trunk/ reaver-latest

There is more info available here: 
http://code.google.com/p/reaver-wps/source/checkout

Original comment by cheff...@tacnetsol.com on 11 Jan 2012 at 1:09

[GoogleCodeExporter]

Thanks! Apparently I already have subversion. I viewed the first link and 
wasn't sure what to do there so I downloaded reaver.db. Then visited the second 
link and ran the command in Terminal. Is there anything else I need to do? I 
really appreciate the hand holding. I will learn this if it kills me!

Original comment by Garyv...@gmail.com on 11 Jan 2012 at 1:18

[GoogleCodeExporter]

If you ran the 'svn checkout' command, it should have created a directory for 
you. That directory should be named whatever the last argument was to the svn 
checkout command (reaver-latest, reaver-wps-read-only, whatever it is that you 
called it).

Inside that directory you should have the src and docs directories. The src 
directory contains all of the latest code, so just cd to the src directory and 
build it:

$ ./configure
$ make
$ sudo make install

If you don't already have them, you will need to install the libsqlite3-dev and 
libpcap-dev packages first (if ./configure command above complains about these 
missing libraries, then you don't have them on your system):

$ sudo apt-get install libsqlie3-dev libpcap-dev

Original comment by cheff...@tacnetsol.com on 11 Jan 2012 at 1:24

[GoogleCodeExporter]

Okay, I did all that and it went fine. Then I get this on the last command: 
(sudo make install)

# sudo make install
if [ ! -d /usr/local/etc/reaver ]; then mkdir /usr/local/etc/reaver; fi
cp reaver.db /usr/local/etc/reaver/reaver.db
chmod -R a+rw /usr/local/etc/reaver
if [ -e walsh ]; then cp walsh /usr/local/bin/walsh; fi
if [ -e reaver ]; then cp reaver /usr/local/bin/reaver; fi
cp: cannot create regular file `/usr/local/bin/reaver': Text file busy
make: *** [install] Error 1

Original comment by Garyv...@gmail.com on 11 Jan 2012 at 1:38

[GoogleCodeExporter]

I figured that issue out. I needed to stop reaver first.... So I ran it again 
after I stopped it and I get this:

# sudo make install
if [ ! -d /usr/local/etc/reaver ]; then mkdir /usr/local/etc/reaver; fi
cp reaver.db /usr/local/etc/reaver/reaver.db
chmod -R a+rw /usr/local/etc/reaver
if [ -e walsh ]; then cp walsh /usr/local/bin/walsh; fi
if [ -e reaver ]; then cp reaver /usr/local/bin/reaver; fi

Original comment by Garyv...@gmail.com on 11 Jan 2012 at 1:45

[GoogleCodeExporter]

Should be installed and ready to go!

Original comment by cheff...@tacnetsol.com on 11 Jan 2012 at 1:47

[GoogleCodeExporter]

Awesome! Thank so so much for your patience. This is the new output. Is this 
normal?

[+] Trying pin 46375674
[+] Sending EAPOL START request
[+] Sending identity response
[+] Sending M2 message
[+] Sending M4 message
[+] Sending WSC NACK
[+] Trying pin 62135672

Original comment by Garyv...@gmail.com on 11 Jan 2012 at 1:50

[GoogleCodeExporter]

Yes, the latest code prints out more detailed information about which WPS 
packets it is sending. It looks like the attack is going along fine. :)

Original comment by cheff...@tacnetsol.com on 11 Jan 2012 at 1:55

[GoogleCodeExporter]

You are my hero. Thanks again!

Original comment by Garyv...@gmail.com on 11 Jan 2012 at 1:56

[GoogleCodeExporter]

How do you update reaver in backtrack5? is the a command to do it easy?

Original comment by szymonpi...@googlemail.com on 13 Jan 2012 at 11:43

[GoogleCodeExporter]

Cheff,

i follow you what you say and complete installed, but still no go, keeping try 
on same number. i try about 3 hr, just complete 0.17%

Original comment by nelson...@gmail.com on 20 Oct 2012 at 3:11