Prioritizing authentication pkts & resending failed EAPOL pkts?

[Ben Greear]

On 02/04/2011 09:32 AM, Jouni Malinen wrote:
> On Fri, Feb 04, 2011 at 12:48:29PM +0100, Bj?rn Smedman wrote:
>> I have experimented with delaying EAPOL messages between hostapd and a
>> supplicant (in this case Mac OS X). A simple delay of a hundred
>> milliseconds or so leads to similar problems. Unfortunately we didn't
>> have time to fully debug the problem but we came to the conclusion
>> that if hostapd's EAPOL retry logic triggers the state machines in
>> hostapd and the supplicant seem to loose sync in some way and the
>> 4-way handshake fails. The following patch solved this problem for us:
>
> This sounds like a bug somewhere.. After the relaxed matching rules for
> replay counter (commit 22a299ee9d192d06c235428d017234539fbf6a62 from
> December 2008), hostapd should allow response to any of the pending
> EAPOL-Key frame TX attempts, i.e., it would be enough for the station to
> get the reply out in four seconds or so. Before that, the limit was one
> second since the reply had to be received before the next TX attempt.
>
> If you get chance to look at this in more detail at some point, it would
> be interesting to see a wireless capture showing a failure case with
> that supplicant.
>
>> -static const u32 eapol_key_timeout_first = 100; /* ms */
>> -static const u32 eapol_key_timeout_subseq = 1000; /* ms */
>> +static const u32 eapol_key_timeout_first = 1000; /* ms */
>> +static const u32 eapol_key_timeout_subseq = 2000; /* ms */
>
> This should be fine in general, but it will delay connection if the
> first EAPOL-Key frame is lost for any reason. In addition, it should be
> noted that the timeout values in the IEEE 802.11 are _much_ tighter than
> these, so if you have a station that has problems with the values used
> in hostapd, expect issues with other AP implementations..

Jouni:  I'm ever hopeful that someday my patches will have a shot
at upstream inclusion.  For this particular change, would it be
more acceptable to have these as configurable values so that users
can set the higher timeouts if desired?  (I assume that others
would be very happy with the current timeouts, so the patch as is
might not be acceptable for upstream inclusion.)

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com