wpa_supplicant Windows port, again (WPA2)

[Bryan Kadzban]

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.

I have debug logs (-ddt) from both a successful key exchange and an
unsuccessful one, but I can't attach everything or my mail goes over the
25k size limit.  I also have corresponding packet captures (from
airsnort's windows port, running on another machine).  A gzipped copy of
the captures from both attempts are attached.  I can provide the log
files if needed, but they'll have to be in 2 separate messages.  Maybe
this will be enough to point out the problem?

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.

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.

So, does anybody know enough about the 4-way handshake to know what's
failing here?  I suspect the windows drivers, myself, but it might also
be either the cards themselves or something else, I'm not sure.  Again,
if you want the capture (or log) from the successful attempt, let me
know, but they'll have to come in 2 separate messages due to the 25k
size limit.

Thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cap-broken.pkt.gz
Type: application/gzip
Size: 7565 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050922/adcea653/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cap-working.pkt.gz
Type: application/gzip
Size: 8385 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050922/adcea653/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050922/adcea653/attachment.pgp