wpa_supplicant + madwifi <--Peap--- SenaoAP ---Peap--> freeradius

[Jouni Malinen]

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
> http://www.vigor.co.za/linux/wpa_supplicant_20050504.txt
> http://www.vigor.co.za/linux/freeradius_20050504.txt
> 
> wpa_supplicant
> network={
> 	ssid="wireless_11g"	
> 	key_mgmt=WPA-EAP
> 	eap=PEAP
> 	pairwise=TKIP
> 	group=TKIP
> 	identity="user at vigor"
> 	password="foobar"
> 	#anonymous_identity="anonymous"
> 	#ca_cert="/etc/cert/ca.pem"
> 	#phase1="peaplabel=1 includes_tls_length=1" <<Does not change anything.	
> 	phase2="auth=MSCHAPV2"
> 	priority=2

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
Handshake,

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
exchanged.

-- 
Jouni Malinen                                            PGP id EFC895FA