Closed GoogleCodeExporter closed 9 years ago
I have this same issue.
It happens from the first pin attempt.
I'm using BT4r2 with a AWUS036NH rt2800usb
Original comment by tomrile...@gmail.com
on 3 Jan 2012 at 12:07
Same here, reaver never gets past first pin attempt.
Using svn r38 and AWUS036NH rt2800usb in BT5r1 VM.
Original comment by bramrob...@gmail.com
on 3 Jan 2012 at 1:13
@tomriley, bramrobyns:
We've had multiple reports of issues using the rtl2800usb driver. I'd suggest
trying a different card if you have one.
@hacked:
The APs may be locking you out. Please provide pcaps.
Original comment by cheff...@tacnetsol.com
on 3 Jan 2012 at 2:01
@hacked:
Also, how long did you let it run once you started getting these errors?
Original comment by cheff...@tacnetsol.com
on 3 Jan 2012 at 2:01
For everyone who using AWUS036NH rt2800usb in BT5 R1.
Read this
http://www.backtrack-linux.org/wiki/index.php/Wireless_Drivers
Original comment by hurenhan...@googlemail.com
on 3 Jan 2012 at 2:09
@hurenhan
The AWUS036NH is absolutely terrible with BT5 R1.
I've long given up trying to get it work, gone back to BT4 R2.
Original comment by tomrile...@gmail.com
on 3 Jan 2012 at 3:26
I tried it in BT4 R2 r48 without success.
root@bt:~# reaver -i mon0 -b 7C:4F:B5:49:7D:03 -vv
Reaver v1.1 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffnerl.com>
[+] Waiting for beacon from 7C:4F:B5:49:7D:03
[+] 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 10
[+] Switching mon0 to channel 11
[+] Associated with 7C:4F:B5:49:7D:03 (ESSID: ARMANI2011)
[+] Trying pin 28623991
[!] WARNING: Receive timeout occurred
[!] WARNING: Receive timeout occurred
[!] WARNING: Receive timeout occurred
[!] WARNING: Receive timeout occurred
[!] WARNING: Receive timeout occurred
[!] WARNING: Receive timeout occurred
Original comment by hurenhan...@googlemail.com
on 3 Jan 2012 at 3:56
OK guys, I can't diagnose these problems without pcaps.
My guess is that the timeouts are due to 1) interference/signal strength
issues, 2) APs that have locked/disabled WPS, or 3) driver issues. I'm leaning
towards #3, since everyone here has reported using rt2800usb, which has
generally seemed to not work very well. But again, without pcaps I can't tell
anything for sure.
Original comment by cheff...@tacnetsol.com
on 3 Jan 2012 at 4:07
@hurenhan
Thanks for the link. I have read that page as well thinking it was a driver
issue but the card is supported. Further, I do get a successful attack
started, up to 5.5% roughly and then it simply begins to error out. If I
CTRL+C the attack and begin again, the attack runs as expected until about 5.5%
which obtains the same result as previous.
Original comment by hacked.y...@gmail.com
on 3 Jan 2012 at 4:07
hurenhan, this sounds like the AP is locking WPS. Did you get the "rate
limiting detected..." warnings at all? I didn't see them in the snippet you
posted above.
Original comment by cheff...@tacnetsol.com
on 3 Jan 2012 at 4:10
@cheff
I can attach a pcap file but it will be rather large. As I say, the attack
begins fine to about 5.5% (+- 1%) and then errors out. If it will still be of
help I can surely do this.
Original comment by hacked.y...@gmail.com
on 3 Jan 2012 at 4:28
No rate limiting warnings, just the receive timeout error
Original comment by hurenhan...@googlemail.com
on 3 Jan 2012 at 4:28
PLS help me
How can i scan this function "scan for WPS enabled APs."? (for 1.3 ver)
Original comment by burakozy...@gmail.com
on 3 Jan 2012 at 4:35
@hacked:
Yes, a pcap would be appreciated.
@burak:
Not the right place for this question, but you need to use the walsh utility
included with v1.3 to do the scans.
Original comment by cheff...@tacnetsol.com
on 3 Jan 2012 at 4:54
A little offtopic, is there a capture of WPS breaking process?
Original comment by xpeh.o...@googlemail.com
on 3 Jan 2012 at 5:06
@cheff
v 1.3 clean installed
Command used: reaver -i mon0 -b 38:60:77:81:AF:1D -S -vv
Now the attack goes no further than 1%. Only difference is the -S switch is used
Cannot attach cap file as it is 23MB (told you it would be large) and I am
limited to 10MB/comment. Best I can do is link to cloud storage at
http://www.wupload.com/file/2633777887/25successivefails
Original comment by hacked.y...@gmail.com
on 3 Jan 2012 at 5:41
Thanks hacked, downloading it now.
I did notice that some APs didn't seem to respond well to the small DH keys,
which is why I made it an option in Reaver instead of the default. Could be an
implementation issue on my end, but other APs churn along quite nicely with the
-S option.
Original comment by cheff...@tacnetsol.com
on 3 Jan 2012 at 6:10
Looks like it's getting stuck in a loop of M2D/WSC_ACK messages. M2D doesn't
really do Reaver any good, so I've removed support for M2D messages; see if
that helps.
Original comment by cheff...@tacnetsol.com
on 3 Jan 2012 at 6:39
Original comment by cheff...@tacnetsol.com
on 3 Jan 2012 at 6:40
Here is a pcap using the same command but without the -S switch. Perhaps it
may assist in determining if DH Small Packets are contributing to the cause.
http://www.wupload.com/file/2633803282/25successivefails2
Original comment by hacked.y...@gmail.com
on 3 Jan 2012 at 6:52
reaver 1.3 rev 49
many error messages that cause retransmission of same PIN so attack is going
very slow.
12.56% complete @ 2012-01-03 20:14:14 (93 seconds/attempt)
!] WARNING: 10 failed connections in a row
[+] Trying pin 63818246
[!] WARNING: Receive timeout occurred
[+] 12.56% complete @ 2012-01-03 20:17:00 (98 seconds/attempt)
PCAP attached if any help to determine cause/issue
Original comment by hacked.y...@gmail.com
on 4 Jan 2012 at 2:19
Attachments:
It looks like your timeouts are different than the one you previously posted.
Before it looked like Reaver was getting stuck in a loop sending/receiving
M2D/WSC_ACK messages; now it just looks like Reaver is having problems
initiating a WPS session, which given that the RSSI of the AP is -63dbm, is
expected.
I have made some code changes though; can you check out r53, try it, and post a
pcap? I want to ensure that there aren't any additional issues there. Thanks!
Original comment by cheff...@tacnetsol.com
on 4 Jan 2012 at 2:35
No thanks needed, I am glad to assist. If anything I should be saying thanks
for the assistance into the issue that not only helps me, but possibly others.
Reaver 1.3 rev53
Still many error messages and slow attack, but there does not appear to be the
25 Successive Failure errors any longer.
I can try a stronger AP however that may change results here and introduces a
new variable for troubleshooting. If you think it would be beneficial, I can
try a stronger AP.
PCAP attached
Original comment by hacked.y...@gmail.com
on 4 Jan 2012 at 2:53
Attachments:
Just to be certain I am not making any errors here. here is my process for
applying revision.
CTRL+C current running reaver
svn checkout http://reaver-wps.googlecode.com/svn/trunk/ reaver-wps-read-only
-r53
resume attack
Please advise if incorrect.
Original comment by hacked.y...@gmail.com
on 4 Jan 2012 at 3:03
It looks like the M2D bug that I saw earlier has been fixed. Looking at the
RSSI reported in the radio tap header of the target AP's beacon packets, the
signal strength is only -68dbm, which is pretty low. Given this, the failures
I'm seeing in the pcap are pretty much expected.
If you can try a stronger AP, something around -50dbm or better (the only
strong one I saw in the pcap was the 2wire AP, and that doesn't appear to
support WPS), you should get much better results.
Original comment by cheff...@tacnetsol.com
on 4 Jan 2012 at 3:03
Yes, that is the correct svn usage. Make sure of course that you're building
the code after you check it out. :)
Original comment by cheff...@tacnetsol.com
on 4 Jan 2012 at 3:09
@cheff "Make sure of course that you're building the code after you check it
out."
can you elaborate what you mean by this please. As I said, I am rather noob
with nix still, but I do try to research first before asking.
I will try swapping out the antennae to a directional 5dBi and hope this will
improve signal strength. As you saw there are many networks and I believe this
is contributing to the noise. The 2Wire is the strongest as it is about 6'
from the antennae. I am suprised that the signal would not be stronger.
Original comment by hacked.y...@gmail.com
on 4 Jan 2012 at 4:34
@cheff
FEEDBACK:
After updating to r53 due to r49 issues, I can advise issue seems to be
resolved. I tried an ap that was 3dBi stronger and all went well. There was a
brief period about the 15% - 18% part of the attack that many errors occurred
(causing attack to go from attempt/4sec to attempt/52 sec) but did subside.
ISSUE 59 can be considered resolved from my perspective.
Original comment by hacked.y...@gmail.com
on 4 Jan 2012 at 9:12
Great, thanks!
Original comment by cheff...@tacnetsol.com
on 4 Jan 2012 at 1:01
How can I update my reaver to r53 ?
Original comment by elite-he...@hotmail.com
on 4 Jan 2012 at 6:32
I had this problem as well, running for idk 3 hours. At about 6.5 %. with the
command
reaver -i mon0 -b xx:xx:xx -c 6 -S -vv
I tried a couple more times but last time I took out the -S and it started
running fine again.
Original comment by Infectio...@gmail.com
on 5 Jan 2012 at 10:05
Original issue reported on code.google.com by
hacked.y...@gmail.com
on 3 Jan 2012 at 7:35