complement tip: "On the fly mac changer" or other solution to dodge lockdowns about reaver-wps

[GoogleCodeExporter]

From the APs that I've tested none of them lock on a specific MAC address, just 
on a failed number of attempts (although it's possible some might). 

The problem with MAC spoofing is that Reaver uses libpcap for injection and in 
my experience it doesn't like it when you spoof the MAC (though this may be 
driver-specific). Will look into it some more when I get a chance.

Original comment by [email protected] on 31 Dec 2011 at 4:51

[GoogleCodeExporter]

what if, you didn't spoof the mac.
but used multiple wireless cards?
(i had started on a comparator setup for pin pointing an AP)
(i would test this out now but i am still waiting on some hardware)
what if the option was given in the software to use 4 wireless cards?
(this would only work on a laptop with usb) 
but breaking the duty in to pieces may shorten the time needed to test pins
by a factor of X. (2 cards = 1/2 the time, 4 cards = 1/4 ect..)

Original comment by [email protected] on 31 Dec 2011 at 12:29

[GoogleCodeExporter]

More clients trying probably would mean a lot of work for the AP processor, and 
probably a lock down or a restart. It was discussed on the advissory pdf

Original comment by [email protected] on 31 Dec 2011 at 12:38

[GoogleCodeExporter]

I have tried multiple cards and attack systems. As maguila said, the issue is 
that the bottleneck is in the AP since it is a small embedded device with 
limited resources. Some APs can't handle multiple registrars at all and having 
more than one causes neither instance of reaver to be able to test any pins.

However, simply having two MACs and rotating in round-robin fashion may help 
with the lock outs on some APs. As I said it hasn't seemed to help on any of 
the ones I've tested, but this is something I'd like to look into.

Original comment by [email protected] on 31 Dec 2011 at 1:22

[GoogleCodeExporter]

I agree with cheff. I too noticed with the APs I tested that changing the mac 
address wouldn't help once you get the message: "WARNING: Detected AP rate 
limiting, waiting 315 seconds before re-trying"

Original comment by [email protected] on 31 Dec 2011 at 2:48

[GoogleCodeExporter]

Original comment by [email protected] on 2 Jan 2012 at 3:33

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by [email protected] on 2 Jan 2012 at 6:19

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I'm currently experimenting with the -d option to circumvent those 
bottlenecks.Maybe if we set it long enough, the AP will think that a new device 
is trying to make contact. It slows down the process, but hopefully it will 
outsmart the lockdown

Original comment by [email protected] on 3 Jan 2012 at 11:28

[GoogleCodeExporter]

AP-specific options can now be added to the Reaver database (need latest SVN 
code) and applied automatically, so if you find options that work well for a 
given AP, you can add them there. Unfortunately there doesn't appear to be much 
we can do at the moment to circumvent lockdowns.

Original comment by [email protected] on 3 Jan 2012 at 2:09

• Changed state: WontFix

[GoogleCodeExporter]

Not sure if anybody still wants this feature, but I decided to add it.

Original comment by ATARIVampire on 10 May 2013 at 12:40