Question regarding WPA-PSK 4-way EAPOLs (wpa-supplicant 0.3.9)

Bar, Eitan eitanb
Thu Sep 29 00:58:29 PDT 2005


Regarding the "missing" AP RSN IE, I just saw that indeed the code
supports driver providing of AP RSN IE inside EVENT_ASSOCINFO event. So
I'll just use that :)

BTW, re the 1st issue (2nd EAPOL not accepted by AP) - when I do disable
WME I do receive the 3rd EAPOL (and then the 2nd issue with the missing
AP RSN IE arises). Anyways, I will post more info once I have it.

Thanks :)
-----Original Message-----
From: at
[ at] On Behalf Of Bar, Eitan
Sent: Thursday, September 29, 2005 8:09 AM
To: hostap at
Subject: RE: Question regarding WPA-PSK 4-way EAPOLs (wpa-supplicant

Hi Jouni,

My responses/questions are inline.
I've also attached an airopeek sniffer capture of the 1st issue. Id
appreciate any comments :)

Thanks again,

-----Original Message-----
From: at
[ at] On Behalf Of Jouni
Sent: Thursday, September 29, 2005 5:08 AM
To: hostap at
Subject: Re: Question regarding WPA-PSK 4-way EAPOLs (wpa-supplicant

On Wed, Sep 28, 2005 at 03:53:10PM -0600, Eitan Bar wrote:

> 1st EAPOL from the AP (Cisco 1200) is received, and when
wpa_supplicant generates the 2nd EAPOL, there
> seems to be something wrong with it (AP repeating 1st EAPOL).

I would guess that timeout on the AP side would be the main reason for
this. I would suggest verifying whether the same issue shows up with
wpa_supplicant v0.4.5 (test both with and without debugging).

[Eitan Bar] Timeout in Cisco APs is 100ms. Sniffer captures show that
wpa_supplicant responded quicker than that (with debug msgs turned off).

> All fields in EAPOL seem ok and according to spec, but could it be
that the MIC Calculated is wrong?


[Eitan Bar] Could there be some kind of alignment/endian issues when
calculating the MIC? 

> Is there a way or some special DBG msgs to look for?

For this, you would need to look at the AP debug log. Cisco 1200 has
quite verbose debugging, so it could explain why message 2/4 is

[Eitan Bar] I'll try hooking up a console and check that..Thanks

> Could this be related to WME being enabled on both driver and AP ?

Should not be; the driver takes care of process the extra QoS control
field in the data frames, so the EAPOL-Key frames look exactly same as
they would without WMM.

> I've seen an earlier thread about this, but that ended with the guy
disabling WME and that was it.

Hmm.. I don't remember reading this kind of report. I don't remember
whether I have explicitly tested wpa_supplicant with both WPA and WMM
enabled on Windows, but I would guess I have.

 [Eitan Bar] I will do more testing and let you know (if you're

> While trying PSK association with another AP with WME disabled, I've
seen that the wpa_supplicant,
> once receiving the 3rd EAPOL (from the AP) which contains the APs RSN
IE (or part of it), prints a msg
> that it couldn't find an AP with this RSN IE (probably since ap_scan=2
therefore no beacon/probeRsp IE 
> are kept in memory).
> It then tries to retrieve scan_results from the driver.
> Assuming I do not wish this to happen and still have ap_scan=2, what
am I missing here?

Why would you not want this to happen?

[Eitan Bar] I simply wish that the RSN IE would some how be reported or
brought to the wpa supplicant's attention BEFORE the EAPOL handshake.
I'm afraid that calling the driver for scan results and all the data
transfer and context switching between user mode and kernel mode might
require more time and cause EAPOL Timeout on AP.

I think maybe I can patch the code to include AP RSN IE in association
info as well? Do you think that would be a wise thing to do? (I see no
other alternatives if I really want to avoid supplying the RSN IE during
EAPOL handshake).

> Is this a must ? (APs IE kept for EAPOL handshake?)

Yes, supplicant needs to verify that the WPA/RSN IE in message 3/4
matches with the IE sent in Beacon/Probe Response frame in order to
detect a downgrade attack.

[Eitan Bar] Ok :)

> Is the driver Assoc REQ RSN IE not enough?

No, this comparison is to verify AP's WPA/RSN IE which is not included
in association req/resp frames.

[Eitan Bar] Thanks :)

> Jan 01 00:24:54.583190: NDIS: ReqFixed=0x3 RespFixed=0x7 off_req=44
off_resp=102 len_req=58 len_resp=17
> Jan 01 00:24:54.583971: NDIS: association information - IE overflow
> Jan 01 00:24:54.584432: NDIS: Request IEs - hexdump(len=58): 00 07 65
69 74 61 6e 54 49 01 05 82 84 8b 96 2c 32 08 0c 12 18 24 30 48 60 6

Hmm.. Do you know why that IE overflow is being reported? Your debug log
was not verbose enough to include the full association information from
the driver (this would require -dd to get MSG_MSGDUMP level of debugging
printed out), so I cannot verify whether the data was valid. This
overflow message should only be reported if the NDIS driver returns
incorrect data (length of the assoc info is less than req/resp
offset+len). In addition, that "Request IEs" line should not be showing
up unless you have modified wpa_supplicant to ignore the overflow error.

[Eitan Bar] These are actually some of the prints I've added to debug
the Assoc Req/Resp responses from the driver.
Since it returns len=0 (internal driver implementation issue), it shows
as an overflow, but I am pretty certain this is not the case here. I
will remove these prints.

> Jan 01 00:24:55.110847: WPA: No WPA/RSN IE for this AP known. Trying
to get from scan results
> wpa_driver_get_scan_results called - not implemented and SHOULD NOT BE
CALLED if ap_scan=2 !

This is an invalid comment. get_scan_results is needed to get the
WPA/RSN IE from the BSSID_LIST. In ap_scan=2 mode, this does not need to
do a scan of other APs or report any other BSSIDs that the one that the
client is currently associated with. Including this BSS in
OID_802_11_BSSID_LIST is required by the NDIS spec.

[Eitan Bar] I agree, I just didn't think/know the wpa_supplicant might
require scan results (since I requested driver do the
scan/selection/cipher/IE etc). But I accept your comments :)

Jouni Malinen                                            PGP id EFC895FA
HostAP mailing list
HostAP at
HostAP mailing list
HostAP at

More information about the Hostap mailing list