Hostapd to Wpa_supplicant 4 way Handshake Problem
sbrown at cortland.com
Mon Sep 22 07:42:34 EDT 2008
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?
> HostAP mailing list
> HostAP at lists.shmoo.com
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...
More information about the HostAP