Prioritizing authentication pkts & resending failed EAPOL pkts?

[Björn Smedman]

On Fri, Feb 4, 2011 at 7:05 PM, Ben Greear <greearb at candelatech.com> wrote:
> 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.
>>

I'm based on 0b86f67a2970403d1b1b6d34ce49f5485ef5dbb3 which is much
later and seems to have the relaxed replay counter check.

>> 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.

If I get a chance to run the delay test I will send a dump file.

>>> -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..
>
> Initial testing shows that this patch is a big help. ?I had no problem getting
> 128 stations to associate. ?Traffic is running better too..probably
> because interfaces are not constantly re-associating & re-authenticating.

Do you have any thoughts as to why it helps? It sounds a little bit
like it could be that the total timeout (all retries) is longer. But
in my case I'm relatively sure that no EAPOL frame is delayed long
enough for all retries to fail. It seems that for me either the first
attempt is successful and the retry logic is never triggered, or the
4-way handshake fails.

How about another combo of timeouts? E.g.

 +static const u32 eapol_key_timeout_first = 1000; /* ms */
 +static const u32 eapol_key_timeout_subseq = 500; /* ms */

should have approximately the same total timeout as the original code
while at the same time having a better chance of avoiding the first
retry being triggered. If this helps then something is fishy, right?

As soon as I get a chance I'm going to try

 +static const u32 eapol_key_timeout_first = 1; /* ms */
 +static const u32 eapol_key_timeout_subseq = 1000; /* ms */

on my home router. If I understand correctly this should waste
bandwidth and time but still work with a sane supplicant, no?

/Bj?rn