wpa_supplicant + madwifi <--Peap--- SenaoAP ---Peap--> freeradius
jkmaline at cc.hut.fi
Sun May 8 15:03:21 EDT 2005
On Wed, May 04, 2005 at 09:44:28PM +0200, Pieter E Smit wrote:
> I am connecting with a madwifi (wpa_supplicant) to a senao AP with wpa
> peap and freeradius server.
Which version of wpa_supplicant and FreeRADIUS are you using? Which
Senao AP model is this and what firmware version are you using?
> Full Dump
> identity="user at vigor"
> #phase1="peaplabel=1 includes_tls_length=1" <<Does not change anything.
includes_tls_length is a typo (should be include_tls_length), but
anyway, this is not needed with FreeRADIUS.
This wpa_supplicant configuration file does not seem to be complete,
i.e., the debug log shows other fields than the ones included here..
> EAP-PEAP: received Phase 2: code=1 identifier=98 length=11
> EAP: EAP entering state RECEIVED
> EAP: Received EAP-Success
> EAP: EAP-Success Id mismatch - reqId=89 lastId=98
> EAP: EAP entering state DISCARD
There is something odd going on with the EAP identifiers.. I've never
seen this kind of behavior with FreeRADIUS, so I would guess the AP
(IEEE 802.1X Authenticator) could be doing something weird..
Would it be possible for you to make a capture log of EAPOL packets
between the Supplicant and Authenticator (e.g., run tcpdump or ethereal
on the client) and another capture log of RADIUS packets
(tcpdump/ethereal on the host running FreeRADIUS)? Getting these capture
files from the same authentication attempt would be quite helpful for
understanding what is happening here.
> And it continues with tls peap etc.
> Q1. The line "EAP: Received EAP-Success" does this mean i have been
> authenticated ?
This means that the authentication server believed that EAP
authentication was completed successfully.
> Q2. "EAP: EAP-Success Id mismatch - reqId=89 lastId=98" i see often, it
> seems the ap is sending new requestes during the authentication. Is this
> a problem ?
Yes, wpa_supplicant is ignoring the EAP-Success packet since it had
incorrect identifier. This will break the following WPA 4-Way Handshake
since wpa_supplicant does not believe that EAP was completed and as
such, it cannot get the pairwise master key needed for the 4-Way
As a workaround, you could consider changing eap_success_workaround()
function in eap.c to always return 1 (e.g., add "return 1;" as the first
line in that function). This should allow the 4-Way Handshake to be
started properly. Anyway, I would like to understand what is happening
here, so the capture logs I mentioned above would still be helpful even
if this workaround would allow the authentication to be completed.
> Q3. "How do I know if the AP and supplicant has exchanged keys ?
With WPA, wpa_supplicant debug log will show "WPA: Key negotiation
completed with <BSSID> [PTK=<TKIP/CCMP> GTK=<TKIP/CCMP>" when the WPA
key handshake has been completed and data encryption keys have been
Jouni Malinen PGP id EFC895FA
More information about the HostAP