madwifi WPA

[Sam Leffler]

On Thursday 08 July 2004 08:30 pm, Jouni Malinen wrote:
> 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: [1] 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?

I'm probably skipping encryption of all frames with EAP frame type; will need 
to investigate.

>
> 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)

I'd need to see a packet dump to fully understand this.  The current scanning 
code is rather stupid and needs an overhaul.  I suspect you're hitting an 
issue in the caching of existing scan results.

Best to take this offline or to the madwifi 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
> anymore.. ;-)