Hostapd to Wpa_supplicant 4 way Handshake Problem

[Steve Brown]

Damon Southworth wrote:
> Re: http://lists.shmoo.com/pipermail/hostap/2008-August/018193.html
>
> 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 lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
> !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.

Steve


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: eapol-timeout-1.txt
Url: http://lists.shmoo.com/pipermail/hostap/attachments/20080922/c184690b/attachment.txt