Delay between Association Resp and Eapol-Start

[Jouni Malinen]

On Wed, Oct 16, 2013 at 02:00:28PM +0200, Konstantinos Georgantas wrote:
> I have been troubleshooting the above mentioned issue and I was
> wondering why not to use something like this in eapol_supp_sm.c:
> 
> @@ -288,7 +288,7 @@
>           */
>  #ifdef CONFIG_WPS
>          /* Reduce latency on starting WPS negotiation. */
> -        sm->startWhen = 1;
> +        sm->startWhen = 0;
>  #else /* CONFIG_WPS */
>          sm->startWhen = 3;
>  #endif /* CONFIG_WPS */
> 
> What complications could such a change introduce when running wps?
> Is there an explicit reason for waiting 1 sec between Association
> Resp and Eapol-Start? I do not see any side-effects when setting
> startWhen to 0.

The main reason for startWhen being initialized to non-zero value is in
avoiding extra frame exchanges since the normal case for initiating IEEE
802.1X/EAPOL authentication is by the authenticator sending out
EAP-Request/Identity frame. If the supplicant sends out EAPOL-Start
message on association that can result in two rounds of EAP Identity
frames.

WPS 1.0 is somewhat of an odd design in this context since it uses
language to mandate the AP to wait for EAPOL-Start before initiating the
exchange. This is an unfortunate workaround for the old spec not
mandating clear indication in the Association Request frame of intent to
go through WPS exchange. This has been fixed in WSC 2.0 to allow the AP
to start EAPOL exchange immediately.

Changing sm->startWhen = 0 could potentially speed up some cases with
old WPS implementations. However, it would result in extra round trips
with more modern implementations and would be undesired for almost all
other uses of EAPOL (e.g., WPA2-Enterprise). As such, I would not
recommend this type of change.

If you are seeing issues with sm->startWhen = 1 with any WPS 2.0 device,
it would be nice to hear more details about the problems. I'm assuming
the only problem you are talking about here is in delaying WPS 1.0
connection by one second.

-- 
Jouni Malinen                                            PGP id EFC895FA