Bug 261 : Race condition when disconnect event arrives during group key handshake
j at w1.fi
Mon Jun 9 04:50:14 EDT 2008
On Thu, Jun 05, 2008 at 09:19:39AM +0200, SOBRIE Olivier AWL-T&P wrote:
> As you can see, the state machine pass from "Group Key Handshake" to
> "Disconnected" and then come back to "Group Key Hanshake". This seems to be
> due to the fact that the first part (1/2) of the group key exchange has been
> received just before the supplicant has been disconnected from the access
> point. After coming back to group key handshake, the second message of the
> group key is sent and the state pass from GROUP_HANDSHAKE to COMPLETED but
> we are disassociated... Wpa supplicant think it is connected and will never
> start a new scan.
> To solve this problem I used workaround that consists of removing the
> eloop_cancel_timeout on the scan in wpa.c :
> This way when the disconnect event occurs, the scan that is launched is not canceled...
> Could someone tell me why there is a cancel on the scan at this place? This
> seems to be there since long time... I assume there is a good reason...
I needed to go four years back in the history to figure this out.. In
April 2004, the authentication timeout was separated from scan timeouts.
Before that, the scan timeout needed to be canceled when the WPA
handshake was completed. However, I do not think that this is the case
anymore. I'm looking into cleaning up the timeout design by not using
the scan timeout at all from the WPA code. This should end up doing the
change you described (in addition to other removals).
As far as the race condition itself is concerned, it would likely be
cleaner to just ignore the group key message if the device is in
disassociated state. I haven't done this for all EAPOL key messages
since there is similar race condition in processing of association
events and received EAPOL frames. In that case, I think there is
workaround code to allow EAPOL frame to be processed before the proper
association event is received. However, group key handshake happens long
enough after the association that I do not think it would hit such a
race condition with association and as such, all group key EAPOL frames
could be dropped if in disassociated state.
Jouni Malinen PGP id EFC895FA
More information about the HostAP