fake authentication variation

[darkAudax]

Greetings,

I have always had major problems using "aireplay -1" fake authentication with my access point.  When you run the command (with the appropriate parameters), it would get all kinds of variations: connected then get a disassociate packets, athenticate but can't associate, and on and on.  Sometimes it would never complete successfully or sometimes take 5 to 8 minutes to be successful.

I finally got fed up and did some experiments.  One thing that I noticed is that the standard fake authentication sends multiple authentication and associate requests out.  My theory was that this was confusing the access point.  So I modified aireplay to only send 1 packet of each instead of multiple.

Bingo!  Aireplay consistently does fake authentication on the first try.

So this same problem likely comes up with other access points and certainly all the access points of the same brand.  So here are my suggestions:

1) Provide an option to override the default built into the program.  This way we can try different numbers of packets.  Maybe different numbers work better on certain APs.  Certainly the quantity of 1 is required on my brand.

2) Provide an option to overide the default time between keep alive packets.  The default is currently 15 seconds.  Personnally I like being able to send them every second.  This way you know for sure you are still associated with the AP.  If you become disassociated then you get know immediately.

Thanks.

d.

[Mister_X]

http://trac.aircrack-ng.org/ticket/44

[Hirte]

your "fakeauth variation" is online, "-o 1" for the packet count and "-q 1" for a one sec delay between keep alive packets.
svn update it

[qedqed]

Working for me! <3

[darkAudax]

Hirte,

Thanks VERY much for so quickly coding this change.

your "fakeauth variation" is online, "-o 1" for the packet count and "-q 1" for a one sec delay between keep alive packets.
svn update it

I tested it and there are two minor problems.

The command line being used: aireplay-ng -1 600 -e teddy -a 00:14:6C:7E:40:80 -h 00:09:BB:EE:EE:EE ath0 -o 1 -q 1

1) In the block of code starting at line 886:
    state = 0;
    x_send = 4;
    if(opt.npackets > 1) x_send = opt.npackets;
    tt = time( NULL );
    tr = time( NULL );

I believe the "opt.npackets > 1" should be "opt.npackets > 0" to cover the case where "-o" is set to 1.  The auth-06.cap file attached shows that when -o is set to 1 that it still generates multiple auth requests.

2) auth-07.cap shows the fake authentication with "-o 1" and "opt.npackets > 0".  The good news is that it only generates one set of packets.  However, now even though -q is set to 1, there are NULL packets every few microseconds.  So I am not sure if code above fixes one thing and breaks another or there is some other problem which causes it to continuously generate keep alive packets regardless of the setting.  The screen only shows one keep alive packet per second.

As an aside, I had a brainstorm.  I don't expect this to be implemented immediately.  Rather it is a dream for the future... Anyways, since there are now multiple ways to get xor files (chopchop, fragmentation), why not have an option to read in the xor file and create a valid keep encrypted keep alive packet.  This would further ensure a solid "connection" to the access point.  If this makes sense let me know and I will open a separate suggestion for it for future implemention.

Again, thanks for the quick coding.

d.

[Hirte]

Both problems should be fixed, changed 1 to 0 and set the number of keep-alive packets to the value set by "-o". Thanks for reporting .

[darkAudax]

Hirte,

Both problems should be fixed, changed 1 to 0 and set the number of keep-alive packets to the value set by "-o". Thanks for reporting .

Darn, you can program 10 times faster then I can test.

Works perfectly!  Thanks.  This will really make it easier with my access point and I am positive that it will be very valuable in the wild.

d.