Open GoogleCodeExporter opened 8 years ago
I notice you are using the -L option. If you don't specify this option do you
get the 'detected AP rate limiting' message?
Original comment by cheff...@tacnetsol.com
on 21 Jan 2012 at 6:02
Can you run the command with -vv for more verbose output?
I had the same problem with an AP where it got stuck at 90.90%
Reaver kept trying the exact same PIN over and over.
Original comment by alibo...@gmail.com
on 22 Jan 2012 at 2:39
I also stopped at 90.90%, and tries again and again the same pin
I do not know what to do, I want to get help
Original comment by uniz...@aol.ru
on 22 Jan 2012 at 4:03
Check this topic: http://code.google.com/p/reaver-wps/issues/detail?id=83
Supposedly this issue has been fixed in the latest source in svn.
Original comment by alibo...@gmail.com
on 22 Jan 2012 at 4:20
unizzon, first make sure you are running the latest SVN code. This was a bug
that has previously been found and fixed. Basically the output you are getting
indicates that reaver has attempted all of the possible combinations for the
first half of the pin but still hasn't found the right one.
However, it has been found that some APs will always report that the first half
of the pin is incorrect (even if it is the right one!) if the AP is in a locked
state. So if you tell reaver to ignore lock outs (-L / --ignore-locks) you can
miss the pin altogether. This is why I asked poiert what happens if he does not
supply the -L option.
Original comment by cheff...@tacnetsol.com
on 22 Jan 2012 at 6:33
i will try again without the -L flag, come back later to say if works
Original comment by poiert2...@gmail.com
on 22 Jan 2012 at 7:40
Hi Craig, I do not use the option - L
2 hours ago made a revision here
http://code.google.com/p/reaver-wps/source/checkout
seems to be written that 109, if not forgotten, and I'm not mistaken.
as a result, all that was before http://www.bild.me/bild.php?file=24880541.png
AP previous two weeks was given properly without such hang-ups, and even with a
jump from 60% to 90%.
I will wait to resolve the situation in the future.
thank you
Original comment by uniz...@aol.ru
on 22 Jan 2012 at 8:05
unizzon, you are going to have to start the attack again, restoring the
previous bad session won't help.
"AP previous two weeks was given properly without such hang-ups, and even with
a jump from 60% to 90%."
Are you saying that Reaver worked on other APs 2 weeks ago, or that you tested
the same AP (74:EA:3A:A9:6A:90) 2 weeks ago and it worked then?
Original comment by cheff...@tacnetsol.com
on 23 Jan 2012 at 12:19
Hi,
I've the same problem, just one input, if I try without ignoring locks, I get 5
minutes AP rating detection systematically, such that it does 60 seconds/pin.
This could turn the attack into days
Original comment by tiago.ju...@gmail.com
on 23 Jan 2012 at 1:39
taigo, there's not much Reaver can do about that. If the AP continues to
respond to WPS pin attempts while "locked", but you never get the right pin and
end up getting stuck at 90.9%, then the AP is probably giving you false
negative reports while it is locked and you'll have to honor the locking
period. Yes, this can make the attack last days, but to put it in perspective a
few days to break a WPA key is nothing.
Original comment by cheff...@tacnetsol.com
on 23 Jan 2012 at 1:54
Cheff, I mean another AP, this is not
Original comment by uniz...@aol.ru
on 23 Jan 2012 at 7:00
i have same problem check image file
http://www.fmsecond.com/di-LNS2.png
Original comment by virusran...@gmail.com
on 23 Jan 2012 at 7:46
It's easy to test if this is the AP returning false negative reports or not:
1) Reboot the AP to ensure a fresh start.
2) Run Reaver with the --pin option, specifying the correct WPS pin for the
target AP to make sure the correct pin works.
3) Run Reaver without --pin, without -L and with -vv and do not restore any
previous sessions.
4) Wait until you start getting "rate limiting detected" warnings.
5) Immediately stop reaver and re-run #2, but this time with the -L option.
Does the correct pin still work or not?
Original comment by cheff...@tacnetsol.com
on 23 Jan 2012 at 2:23
I had this problem, ran without the -L switch and NOW reaver correctly found
the key :) nice
Original comment by kub...@gmail.com
on 25 Jan 2012 at 12:29
Thanks Cheff, without the -L the key was properly found. yeh
Original comment by tiago.ju...@gmail.com
on 28 Jan 2012 at 5:50
Thanks Cheff, reaver 1.4, attack again, all ok, the correct key is found
Original comment by uniz...@aol.ru
on 3 Feb 2012 at 2:12
hi, im kind of new to this cheff, but i have this proble with reaver 1.4
repeating pin at 90.90% . i am not using the -L option or anything other than
-vv. i am also experiences reaver crashing many times and having to restart
from sratch. can you please help me??? thanks
Original comment by slaughta...@gmail.com
on 6 Feb 2012 at 1:25
Same problem here:( iv tried everything mentioned here.
Im using latest trunk 112, iv tried with out without every command. It stalls @
90,90% and i cant get it to continue.
Using it close to my router so that isnt it.
Please help
Original comment by frederi...@gmail.com
on 9 Mar 2012 at 10:20
I'm also stonewalled at 90.90% and I never used the -L switch. Any suggestions?
Original comment by shoredit...@gmail.com
on 18 Mar 2012 at 3:02
same here using rev 113!
Original comment by livewin...@gmail.com
on 28 Mar 2012 at 11:09
[deleted comment]
[deleted comment]
[deleted comment]
I have the same problem at 90.9%.
Reaver is trying the same pin over and over.
I'm very noob, i have to say, but i don't use the option (--ignore-lock)
I use:
reaver -i mon0 -E -L -T 5 -c 1 -b 00:xx:xx:xx:xx:xx -vv
or
reaver -i mon0 -E -L -T 2 -c 1 -b 00:xx:xx:xx:xx:xx -vv
If i don't use the -L option reaver show very "WARNING: Detected AP rate
limiting, waiting 60 seconds before re-checking"
root@bt:~/reaver/src# reaver -i mon0 -b xx:xx:xx:xx:xx:xx -vv
Reaver v1.4 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner
<cheffner@tacnetsol.com>
[?] Restore previous session for 00:26:44:97:4E:65? [n/Y] n
[+] Waiting for beacon from 00:26:44:97:4E:65
[+] Switching mon0 to channel 1
[+] Switching mon0 to channel 2
[+] Switching mon0 to channel 3
[+] Switching mon0 to channel 4
[+] Switching mon0 to channel 5
[+] Switching mon0 to channel 6
[+] Switching mon0 to channel 7
[+] Switching mon0 to channel 8
[+] Switching mon0 to channel 9
[+] Switching mon0 to channel 11
[+] Associated with 00:26:44:97:4E:65 (ESSID: xxx)
[+] Trying pin 12345670
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[+] Trying pin 00005678
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[+] Trying pin 01235678
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[+] Trying pin 11115670
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[+] Trying pin 22225672
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message
[+] Sending M2 message
[+] Received M3 message
[+] Sending M4 message
[+] Received WSC NACK
[+] Sending WSC NACK
[!] WARNING: Detected AP rate limiting, waiting 60 seconds before re-checking
[!] WARNING: Detected AP rate limiting, waiting 60 seconds before re-checking
[!] WARNING: Detected AP rate limiting, waiting 60 seconds before re-checking
[!] WARNING: Detected AP rate limiting, waiting 60 seconds before re-checking
And took one night to make 2,2%.
at this speed it could take a month to reach to 100%.
i use rev 113, alfa aWuso36H in VMware
i have run the command "svn checkout
http://reaver-wps.googlecode.com/svn/trunk/ reaver"
and the "./configure && make && make install"
what sould i do cheff...@tacnetsol.com ?
Original comment by ricardoj...@hotmail.com
on 6 Apr 2012 at 4:55
I am booting backtrack 5r2 from the cd-rom and i got the "request timed out" on
2 different APs after running reaver for a while. the first one stuck at 10%
and the second at 20%
I am simply using reaver -i mon0 -b bssid -vv
i tried adding the --no-nacks argument as well as the -d up to 30 and neither
worked. any advice?
Original comment by pacoo...@abv.bg
on 10 Apr 2012 at 4:48
[deleted comment]
[deleted comment]
[deleted comment]
Same here, on BT5R2 and reaver rev 113, stuck at 90.90% with the 99985677 pin
on "reaver -i .... -b ..... -v" and RTL8187 chipset.
It try the same pin again & again even when I do "-p 99958677" or around.
I've modified the .wps in /usr/local/etc/reaver to force the pin, but nothing
worked.
Let me now if I can help.
Original comment by arnaud.f...@gmail.com
on 4 May 2012 at 4:10
Arnaud, did you recompile and install the program? Just changing the .wps files
won't do any good. Also, I have tried rev 112 and 113 on reaver 1.4 to no
avail, I keep getting the same issue... 90.90%. I know this issue has
supposedly been fixed, but here we are.
BT5R2 Installed to HD
Alfa AWUS036H w/ RTL8187
any ideas? I have tested reaver on other APs and it has been successful.
Original comment by gibp...@gmail.com
on 26 May 2012 at 5:05
Yes, I've recompile reaver and re-install it on BT5R2, on 3 different PC, and
also try it on ubuntu 12.04 and nothing changes, both on 1.3 and last rev of
1.4.
I don't think it's reaver problem, because you say that it work on other AP,
and because the 90.90% seems to be the last bruteforce try of the first part of
pin ("9998"), and the first try of the second part of pin.
So, I think reaver doesn't receive correctly the answer of AP that says the
first part of pin tried is the good one.
I hope it helped!
Original comment by arnaud.f...@gmail.com
on 26 May 2012 at 10:39
It must be a bug, everyone crashes on that number at that percentage% and
certainly that pin isnt the same for all. Not event the beggening part.
Original comment by frederi...@gmail.com
on 13 Jun 2012 at 1:52
Hi. im having exactly same issue. i'm not on my linux OS atm, so i can't post
the exact log.
command im using is this
reaver -i mon0 -b xx:xx:xx:xx:xx:xx -vv -S -w -E -d 29 -x 11
this was original command, but later i removed -w and -E, could those be the
problem causers ?
never used -L option.
also if i set -d to 28 or below, AP will lock WPS for 3-4 minutes. that happend
few times when i was testing, however i did not ignore locks, so i waited until
WPS was unlocked and continued the attack.
Now its stuck at 90.20% and keeps trying same pin 99985677 (i think end was
5677).
I also noticed there is no 9999, so i changed 9998 to 9999, but no difference.
except that it showed 90.90% and 99995677, but no progress.
What should i do ?
Card im using is by TP-LINK with some atheros chipset. supports monitor mode,
able to crack WEP networks..etc
Original comment by mordax
on 28 Jul 2012 at 3:04
Same issue here.
It's stuck at 90.90% and keeps trying pin 99985677 over & over.
I'm using this command:
reaver -i mon0 -b xx:xx:xx:xx:xx:xx -c 4 -v
I hope someone can give us a solution. Thank you.
[I've tried with reaver 1.3, 1.4 R96, etc. and it's stuck at the same % and
same pin. Also I've tried with this command "reaver -i mon0 -b
xx:xx:xx:xx:xx:xx -c 4 -p 9998 -v"]
Original comment by Mo.elyou...@gmail.com
on 2 Sep 2012 at 6:43
Original issue reported on code.google.com by
poiert2...@gmail.com
on 21 Jan 2012 at 3:37