Prioritizing authentication pkts & resending failed EAPOL pkts?

[Jouni Malinen]

On Fri, Feb 04, 2011 at 10:10:50AM -0800, Ben Greear wrote:
> 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.)

I'm hoping to get to your pending patches soon. As far as this timeout
change is concerned, I do not really want to change the defaults that
much. I guess making them configurable could be fine for some very
special use cases, but in general, I would really like to have the
default values work for more or less every case without causing
undesired extra latency for the common cases. It might even be worth
considering to make the initial timeout dynamic in a way that hostapd
would avoid the short timeout if there is a large number of concurrent
4-way handshakes going on. This could drop the number of unneeded
EAPOL-Key frames considerable in cases where you are running out of CPU
or bandwidth during a burst of authentications.

Are you seeing the issues mainly when trying to connect all the stations
at the same time or does this happen even when just connecting a single
station at the time? If you are using WMM, it would be useful to verify
that the EAPOL-Key frames are sent using AC_VO. If not, you may see
quite a bit of help from higher priority if there is considerable amount
of other traffic on the channel at the same time.

If you have some good examples of the issue in wireless capture files,
please send me something for a closer review. I would like to learn
whether the EAPOL-Key frames are completely dropped or whether they just
get delayed too much to hit the timeouts.

-- 
Jouni Malinen                                            PGP id EFC895FA