Thu Jul 8 20:30:18 PDT 2004
On Thu, Jul 08, 2004 at 08:08:43AM -0400, Derek Schuff wrote:
> I ran some debugs on ?sucessful auths with the hostap driver, and also with
> madwifi. I have debugs on the authenticating AP
> (again, not the same as the associating AP), and a few also on the associating
> AP. Looking at the EAP logs on the authenticating AP, they are exactly the
> same for both clients, as far as I can tell, except for the madwifi auth
> repeating itself.
This debug info was very useful, indeed. Thanks for getting the debug
logs from the AP. I did not expect to see any differences for EAP, so,
so far everything is as expected.
> Looking at the associating AP, I think I may have found something interesting:
> Here is an excerpt from the debug on the AP, at this point the EAP auth has been successful and they key handshake is about to take place.
> -----------------> it just got PTK msg 2 from the client, but the key info was apparently invalid?
> dot11_dot1x_verify_ptk_handshake: verifying PTK msg 2 from 0040.96a1.bc2f
> dot11_dot1x_verify_eapol_header: Warning: Invalid key info (exp=0x381, act=0x109
> dot11_dot1x_build_ptk_handshake: building PTK msg 3 for 0040.96a1.bc2f
Somewhat interesting warning. However, completely incorrect.. 0x200 bit
is "Secure" and it is not set at this point. 0x080 is Ack and it is only
set on messages from the AP.. Anyway, the AP did not seem to consider
this to be fatal, since it continued authentication.
> here it sends GTK msg 1 from the client, but the reply is not encrypted (i guess it's supposed to be) and so it's discarded.
> it retries a couple times and gives up
> dot11_mgr_sm_send_gtk_msg1:  Sent GTK msg 1 to 0040.96a1.bc2f
> *** Not encrypted dot1x packet from 0040.96a1.bc2f has been discarded
Indeed, this is the problem. Host AP driver configures the unicast keys
immediately after 4-Way Handshake is completed and the msg 2/2 of Group
Key handshake is encrypted. It looks like madwifi either did not enable
the key immediately or decided not to encrypt the EAPOL-Key frame.
Either way, that prevents the authentication with many (but probably not
all) APs. This messages is indeed supposed to be encrypted.
Sam: Do you know why this Group Key EAPOL-Key packet was not encrypted?
Are you skipping encryption for all packet with EAPOL ethertype (WPA
changed that for cases where pairwise keys are set) or could the group
key configuration cause some odd behavior or maybe there is some timing
related problems in getting the new key in use?
Based on the wpa_supplicant debug log, it looks like the pairwise key
was actually configured:
WPA: RX message 3 of 4-Way Handshake from 00:0c:85:60:f1:f1 (ver=1)
WPA: Sending EAPOL-Key 4/4
WPA: Installing PTK to the driver.
WPA: RSC - hexdump(len=6): 00 00 00 00 00 00
wpa_driver_madwifi_set_key: alg=TKIP key_idx=0 set_tx=1 seq_len=6 key_len=32
WPA: RX message 1 of Group Key Handshake from 00:0c:85:60:f1:f1 (ver=1)
WPA: Group Key - hexdump(len=32): 38 fd 59 49 46 1f ff 68 50 37 0a e0 b0 93 e5 d0 dc 45 e7 bc 52 b7 65 fe aa c8 1b 3f d6 22 5c 30
WPA: Installing GTK to the driver (keyidx=1 tx=0).
WPA: RSC - hexdump(len=6): 00 00 00 00 00 00
wpa_driver_madwifi_set_key: alg=TKIP key_idx=1 set_tx=0 seq_len=6 key_len=32
WPA: Sending EAPOL-Key 2/2
Both keys were received, key indexes look fine, set_tx is ok. However,
that msg 2/2 was not encrypted.
> so there seems to be a problem with the PTK key handshake. I've attached (gzipped) the full log from the AP and also the log from wpa_supplicant,
> which was (hopefully) from the same run. I'm not sure if this is a wpa_supplicant or a madwifi issue, but maybe someone who knows more than me
> can shed some light on it.
PTK key handshake is fine. The only real problem I saw in the debug logs
was in not encrypting msg 2/2.
> A related (but OT for this list I guess) note is that because my AP beacons an
> SSID without WEP but also has an SSID with WEP, (as well as one with WPA) the
> madwifi driver cannot associate to the WEP SSID with WEP enabled. (It will
> associate to the WEP ssid without wep enabled, but as soon as you do iwconfig
> ath0 key xxxx it won't associate at all, presumably because it thinks the AP
> has WEP disabled). I assume this is an issue for the madwifi mailing list, if
> there is one.
Well, the AP is doing something that is not exactly defined in the
standard.. Anyway, if one aims to support multi-SSID configurations, the
client would need to be changed to look at the Probe Response info
instead of Beacon frame for this case. (and yes, this would be more for
the madwifi mailing list)
> Once you use iwconfig to change to managed mode, it works.
> I don't know if it makes sense or is possible for wpa_supplicant to try to put
> the card in managed mode (i assume you could do this for any card using
> wireless extensions) but that might be something to consider, or at perhaps
> at least check the mode and give some clue to the user as to what might be
> going on.
Yes, changing modes automatically sounds reasonable. I have hit this
couple of times myself, but since I'm nowadays setting my laptop to use
Managed mode in the cardmgr scripts, I don't get notified of this
Jouni Malinen PGP id EFC895FA
More information about the Hostap