Closed GoogleCodeExporter closed 8 years ago
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 cheff...@tacnetsol.com
on 31 Dec 2011 at 4:51
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 george.w...@gmail.com
on 31 Dec 2011 at 12:29
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 gorilla....@gmail.com
on 31 Dec 2011 at 12:38
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 cheff...@tacnetsol.com
on 31 Dec 2011 at 1:22
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 jeanbar...@gmail.com
on 31 Dec 2011 at 2:48
Original comment by cheff...@tacnetsol.com
on 2 Jan 2012 at 3:33
Original comment by cheff...@tacnetsol.com
on 2 Jan 2012 at 6:19
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 jage...@gmail.com
on 3 Jan 2012 at 11:28
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 cheff...@tacnetsol.com
on 3 Jan 2012 at 2:09
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
Original issue reported on code.google.com by
NeZZeR.G...@gmail.com
on 31 Dec 2011 at 3:30