Prioritizing authentication pkts & resending failed EAPOL pkts?

Jouni Malinen j
Fri Feb 4 14:43:30 PST 2011

On Fri, Feb 04, 2011 at 10:44:53PM +0100, Bj?rn Smedman wrote:
> 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.

That would be the bug I mentioned about... This is supposed to work with
multiple retries, but of course there can be broken implementations.

As far as the sudden burst of 128 stations showing up at the same time
and with the strict sequencing on this due to the single process
controlling all of them, it sounds very likely that the initial 100 ms
timeout is hit. In practice, this will double the workload and that may
be enough to push things over the limit on CPU use alone.

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

Well.. It depends.. The test case is so odd that it can result in
extra long latency in responses from the station. 1000 ms may be long
enough to avoid hitting the first limit and that would reduce the total
CPU load a lot.

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

Correct, that would likely be fast enough on making hostapd send out two
EAPOL-Key msg 1/4 frames before the response to the first one is
received. This should still work, but sure, it uses about twice the
bandwidth and CPU.

Jouni Malinen                                            PGP id EFC895FA

More information about the Hostap mailing list