wpa_supplicant Windows port, again (WPA2)

[Jouni Malinen]

On Thu, Sep 22, 2005 at 09:08:41PM -0400, Bryan Kadzban wrote:

> So the testing I've been doing with the Windows port of wpa_supplicant
> has been going fairly well.  (I'm running it on 2K.)  But I found out
> yesterday that it's only working with one chipset and one driver --
> other cards and other drivers are having some odd problems.
> 
> The EAP stuff (EAP-TLS) is finishing successfully, but the key exchange
> looks like it's failing.
> 
> According to the debug log, it appears that the AP (Cisco 1100-series)
> isn't recognizing the EAPOL-Key msg 2 of 4 (during the 4-way handshake)
> from the supplicant.  The logs show msg 1 of 4 received, msg 2 being
> built, msg 2 being sent, and then msg 1 being received again.  In the
> meantime, the AP logs an invalid authentication attempt.

Can you get debug log from the AP? It looks like it is rejecting the
authentication for some reason.

> A cursory inspection of these packet captures (using Ethereal as a
> protocol analyzer) shows a couple of differences between the broken and
> working captures.  First, the broken capture doesn't have a PMKID at the
> end of the RSN IE in the second EAPOL-Key message.  I don't know if
> that's a problem or not.

That should be ok, this field is expected to match with the RSN IE from
association request.

> Second, the "replay counter" values may be wrong, though I'm not sure.
> I pulled down the IEEE 802.11i spec, and it says "the authenticator uses
> the replay counter value in frame 2/4 to match the frame to a previous
> frame 1/4 that it sent to that station".  What I'm not sure on is
> whether the replay counter value has to be the same as what was in frame
> 1/4, or it just has to be >= the value in frame 1/4.  These packet
> captures seem to show both, though I'm not exactly sure.

Supplicant is expected to reply with the same replay counter that it
received from the authenticator. The capture log seems to indicate that
there may be timing issues with the authentication. It might be
worthwhile trying to test with a shorter polling interval by changing
l2_packet_receive_timeout() in l2_packet_pcap.c to use 20000 instead of
100000 as the timeout value (i.e., move from 100 ms to 20 ms).

It looks like the WinPcap use will need to be updated to use something
faster than polling for the frames. Unfortunately, this may not work
very well with the current event loop implementation on Windows, so
maybe a second thread is needed to handle this case. Anyway, testing
with more frequent polling could at least verify whether the issues is
indeed in timing.

-- 
Jouni Malinen                                            PGP id EFC895FA