Bug 261 : Race condition when disconnect event arrives during group key handshake

SOBRIE Olivier AWL-T&P olivier.sobrie
Thu Jun 5 00:19:39 PDT 2008

Hello everybody,

One month ago I entered this bug in the bugzilla
Does someone has an idea about this? Is it a known bug?

Below is the interresting part of the trace I took when the problem occured.

RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:00:00:00:00:00
Setting scan request: 0 sec 100000 usec
BSSID 00:14:bf:26:17:d7 blacklist count incremented to 2
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
RX EAPOL from 00:14:bf:26:17:d7
IEEE 802.1X RX: version=1 type=3 length=127
  EAPOL-Key type=254
  key_info 0x391 (ver=1 keyidx=1 rsvd=0 Group Ack MIC Secure)
  key_length=32 key_data_length=32
  replay_counter - hexdump(len=8): 00 00 00 00 00 00 00 07
  key_nonce - hexdump(len=32): 86 0a 98 4f 1f d0 07 1e 32 79 d4 25 dd 97 d2 5c
a3 e0 28 cf 8a ff 8d 35 d1 11 e0 df 37 2c bd d8
  key_iv - hexdump(len=16): a3 e0 28 cf 8a ff 8d 35 d1 11 e0 df 37 2c bd da
  key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00
  key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00
  key_mic - hexdump(len=16): 54 74 ce f3 39 45 6e 5d 06 f6 ec c4 fe 22 c7 4b
WPA: RX message 1 of Group Key Handshake from 00:14:bf:26:17:d7 (ver=1)
WPA: Group Key - hexdump(len=32): [REMOVED]
WPA: Installing GTK to the driver (keyidx=1 tx=0).
WPA: RSC - hexdump(len=6): 00 00 00 00 00 00
wpa_driver_wext_set_key: alg=2 key_idx=1 set_tx=0 seq_len=6 key_len=32
WPA: Sending EAPOL-Key 2/2
WPA: Key negotiation completed with 00:14:bf:26:17:d7 [PTK=TKIP GTK=TKIP]
Cancelling authentication timeout
CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed (reauth) [id=0
wpa_driver_wext_set_operstate: operstate 0->1 (UP)
WEXT: Operstate: linkmode=-1, operstate=6

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 :

--- wpa.c       2008-02-18 01:10:46.000000000 +0100
+++ wpa.c       2008-04-28 10:15:01.000000000 +0200
@@ -1567,7 +1567,6 @@
                MACSTR " [PTK=%s GTK=%s]", MAC2STR(addr),
-       eloop_cancel_timeout(sm->ctx->scan, sm->ctx->ctx, NULL);
        wpa_sm_set_state(sm, WPA_COMPLETED);

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

Thank you.

Olivier Sobrie

(Sorry for the garbage below)

Atos Worldline SA/NV - Chaussee de Haecht 1442 Haachtsesteenweg 
- 1130 Brussels - Belgium
RPM-RPR Bruxelles-Brussel - TVA-BTW BE 0418.547.872
Bankrekening-Compte Bancaire-Bank Account 310-0269424-44
BIC BBRUBEBB - IBAN BE55 3100 2694 2444

"The information contained in this e-mail and any attachment thereto is confidential and may contain information which is protected by intellectual property rights.
This information is intended for the exclusive use of the recipient(s) named above.
This e-mail does not constitute any binding relationship or offer toward any of the addressees.
If you are not one of the addressees , one of their employees or a proxy holder entitled to hand over this message to the addressee(s), any use of the information contained herein (e.g. reproduction, divulgation, communication or distribution,...) is prohibited.
If you have received this message in error, please notify the sender and destroy it immediately after.
The integrity and security of this message cannot be guaranteed and it may be subject to data corruption, interception and unauthorized amendment, for which we accept no liability."

More information about the Hostap mailing list