Prioritizing authentication pkts & resending failed EAPOL pkts?

[Jouni Malinen]

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 Malinen                                            PGP id EFC895FA