AP changes channel, Reaver can't keep up

[GoogleCodeExporter]

0. What version of Reaver are you using?  (Only defects against the latest
version will be considered.)
Reaver 1.4

1. What operating system are you using (Linux is the only supported OS)?

Kali Linux, Debian

2. Is your wireless card in monitor mode (yes/no)?

Yes, mon0

3. What is the signal strength of the Access Point you are trying to crack?

-23dB

4. What is the manufacturer and model # of the device you are trying to
crack?

Linksys WRT54GL.ver.2

5. What is the entire command line string you are supplying to reaver?

reaver -i mon1 -a -s [MAC].wpc -b [MAC] -vv --dh-small -r 50:15

6. Please describe what you think the issue is.

The AP changes channel, but Reaver doesn't detect this somehow. Looking through 
the changelog, this has apparently been an issue before and should have been 
fixed. To fix this, I just Ctrl+C and start Reaver again.
Is there somehow a possibility to add an option to just stop the program and 
re-use the last used command-syntax for getting it started again, after X 
amount of minutes? This would not only fix this particularly problem, but might 
help a lot of other dealing with other issues, that also restarts the program 
as a pseudo-fix.

7. Paste the output from Reaver below.

[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[!] WARNING: 25 successive start failures
[+] Sending EAPOL START request
[+] Sending WSC NACK
[!] WPS transaction failed (code: 0x02), re-trying last pin

... then it just freezes there forever.

Original issue reported on code.google.com by daniel.k...@gmail.com on 18 Jan 2014 at 4:46

[GoogleCodeExporter]

if..in a terminal leave run:
airodump-ng mon0 -d mac  -c channel --ignore-negative-one 
on another leave run:
reaver -b mac -a -S -w -vv -c channel -i mon0 
work?

Original comment by deltomaf...@gmail.com on 18 Jan 2014 at 6:09

[GoogleCodeExporter]

Thank you for your comment!

First of all, I don't understand why you think I should specify a fixed channel 
through the airodump command (--channel), because if the AP suddenly change 
channels from 9 to 6, then airodump will not pick up the APs signals since we 
are using the "-c" syntax to fix airodump scanning only channel 9 (as an 
example).

Now to the other issue using airodump with Reaver. If I set airodump to scan 
all channels while using Reaver, it will constantly hop through channels, and a 
lot of pin requests will not be sent or important packets won't be received.

An example -
airodump-ng scans all APs in the given area, switching channels 2 times per 
second
Reaver is in the background, cracking an AP on channel 9.

It issues pins to the AP, but then since airodump is constantly switching 
channels, the packet is not sent, OR, we didn't recieve any packets back 
because we're on a different channel.

I hope you understand. But I will still try later on to see if your advice 
worked.

Original comment by daniel.k...@gmail.com on 18 Jan 2014 at 7:36

[GoogleCodeExporter]

something is wrong...
By default, if the AP switches channels, Reaver will also change its channel 
accordingly
the airodump will monitor whether the change actually occurs or no.
maybe if specifying -d 20 in line Reaver hope
reaver -b mac -a -S -d 20 -w -vv -c channel -i mon0 

Original comment by deltomaf...@gmail.com on 18 Jan 2014 at 9:19

[GoogleCodeExporter]

Yes, I know!

This was a issue in the previous versions of Reaver, that it did not change 
channel accordingly. Looking through the changelog, I see they've fixed it, and 
Reaver should scan again when the targeted AP changes channel - but it doesn't 
for me. I'm using the 1.4 Reaver version, so it should rescan again. I think 
it's really weird. It only scans in the beginning.

I'm going to test your first suggestion tomorrow using airodump, but I don't 
think it will work.

I will also test with a delay on pin request in the same time, but not today.

Original comment by daniel.k...@gmail.com on 18 Jan 2014 at 9:42