Hostapd to Wpa_supplicant 4 way Handshake Problem

Steve Brown sbrown
Mon Sep 22 04:42:34 PDT 2008

Damon Southworth wrote:
> Re:
> A couple of weeks ago I posted a number of messages regarding problems I
> was experiencing with unreliability of the 4-way handshake re-key. The
> initial 4-way is successful to establish the link but subsequent re-keys
> can be unreliable due to transmission delays and non guranantee of the
> ordering between transmitting the handshake and installing the key.
> I would like to ask a few more questions in relation to this problem.
> This problem still exists and we are still unclear as to the best way to
> solve it. I did monitor the key exchange using a sniffer and managed to
> see that the problem was that the 4/4 message did not get through to the
> AP in time. Two 3/4 retries were seen 100ms apart before the final
> disconnect packet was sent from the AP after a further 100ms.
> In this case the AP was a Cisco 1200 series and the EAPOL messages
> containing the key exchange were sent with a QoS header highest priority
> 7 (management) and were very precise in their transmssion times and
> retries. Packets from the station didn't have a QoS header and timings
> varied with the amount of traffic. Has any thought or work been done to
> allow wpa_supplicant to use the 802.11 QoS extensions and improve the
> delivery of the key exchange. I can see there is support in the Madwifi
> driver for QoS but I am unclear as to the correct kernel interface to
> utilise these extensions. Does information on this exist?
> Regards,
> Damon.
> _______________________________________________
> HostAP mailing list
> HostAP at
> !DSPAM:12584,48b545b030501278799330!
I am having a similar problem.  I am using a current hostapd & 
wpa_supplicant with latest change 9/1/08 along with wireless-testing 
2.6.27-rc6-wl on an i386.

The failures are random and appear as a timeout after sending the first 
handshake 1/4. I enabled timestamps in hostapd and notice that the time 
between the send and the timeout is very short, only a few hundred 
microseconds. The call to eloop_register_timeout sets a 1sec timeout. A 
sniffer confirms the rapid transmit of 2 EAPOL packets, with the second 
appearing within same short time, even before the receiving station has 
time to send an ACK.

I have appended hostapd output from both a successful and failing case.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: eapol-timeout-1.txt

More information about the Hostap mailing list