WPA2/EAPOL handshake problem

[Jouni Malinen]

On Tue, Sep 08, 2009 at 03:46:39PM +0200, Endre Bakka wrote:

> We are trying to get Wi-Fi (Ralink rt73 based usb stick) up an running on
> an embedded platform with uClinux (2.6.28 kernel, rt2x00 driver). It works
> in most cases, but for WPA2-PSK on certain access points (usually Cisco is
> involved) we run into a problem during the EAPOL 4-way handshake.

Which CPU is on that embedded platform? How fast (or well, slow ;-) is
it?

> Long version:
> Log from the AP: http://pastebin.com/f414b6a43
> Log from wpa_supplicant: http://pastebin.com/f52768a93
> 
> Unfortunately the logs are not from the same run (even a different AP  
> used), but the symptoms are identical so should be useful anyway.

It would be useful to see logs from the same run to confirm this, but it
would look like either some of the frames are being dropped and/or the
client side takes way too long time to receive and process the EAPOL-Key
frames.

The AP/Authenticator log seems to indicate that the EAPOL-Key frame is
transmitted three times and the Supplicant is given one second time to
reply to each attempt. Furthermore, the first reply from the Supplicant
is for the second EAPOL-Key transmit attempt (i.e., the first one was
lost) and it is received more than a second after the AP transmitted the
frame to which this is a reply, i.e., it is received only after the AP
has transmitted the next retry.

wpa_supplicant log (from another run, though) indicates that the first
received EAPOL-Key frame is indeed the second one (i.e., first one lost
as shown in the AP log). However, the time spent in processing this
inside wpa_supplicant is about 0.4 seconds, i.e., less than the one
second timeout. However, there may be some additional latency from the
driver.

> I am wondering if latency issues in the embedded device affects the
> handshake, but I've not been able to verify that yet.

How are you recording the wpa_supplicant debug output? If that is sent
through a serial cable, just the part of sending the text may be enough
to add too much latency, especially at 9600 bps.. I would suggest
testing writing the log to a file (e.g., on RAM drive) or disabling
debugging for a test. If that is not enough, a good next step would be
to use a wireless sniffer to capture the frames between the AP and the
station to verify the exact timing on the frames. If the client is
indeed using more than a second to get the reply out, you will need to
try to optimize something to be able to use WPA reliably with all APs.

-- 
Jouni Malinen                                            PGP id EFC895FA