wpa_supplicant not working in Windows

[Jouni Malinen]

On Thu, Oct 13, 2005 at 10:44:58AM +0200, Alicia Caminero Caminero wrote:

>     I'm trying to use wpa_supplicant for Windows
> instead of the Windows one to connect to a wireless
> net which uses IEEE 802.1X with EAP-MD5. All the
> autentication stuff is done by a radius server which
> works fine.

I sure hope that is just a test network since EAP-MD5 over wireless
connection is completely useless from the security view point.

>     My concrete problem is that it seems that, on one
> hand, wpa_supplicant stays in the state
> "Authenticating" endlessly, but on the other hand, the
> radius server says that I've been authenticated
> succesfully. As the wpa_supplicant doesn't know that
> it's been authenticated by the server, it keeps on
> asking for authentication when its timeout expires. 

You have configured wpa_supplicant to expect dynamic keying material
whereas EAP-MD5 does not provide keys for doing this.

> # eapol_flags: IEEE 802.1X/EAPOL options (bit field)
> # Dynamic WEP key required for non-WPA mode
> # bit0 (1): require dynamically generated unicast WEP key
> # bit1 (2): require dynamically generated broadcast WEP key
> # 	(3 = require both keys; default)

You need to set this option to 0, i.e., add eapol_flags=0 into the
network block.

> network={
> 	ssid="lab"
> 	mode=0
> 	key_mgmt=IEEE8021X
> #	scan_ssid=1
> 	eap=MD5
> 	identity="test"
> 	password="test"
> 	eapol_flags=0
> 	wep_key1="1234512345"
> 	wep_tx_keyidx=1
> 	priority=2
> }

I don't remember whether static WEP keys have been tested with IEEE
802.1X. This may or may not work.

> EAP: Received EAP-Success
> EAP: EAP-Success Id mismatch - reqId=130 lastId=132
> EAP: EAP entering state DISCARD

This is quite odd behavior from the authentication server. The last EAP
packet before EAP-Success used id=132 and the EAP-Success packet is
supposed to use the same one. However, it went down.. Do you happen to
know which RADIUS authentication server is used in this network?

The EAP state machine RFC requires that supplicant drops such
EAP-Success frames. wpa_supplicant has a workaround for two common cases
where EAP-Success has last+1 and last+2 Id, but last-2 would a new one
to add for that list; or well, maybe finally just get rid of that
complete verification since there seem to be that many broken RADIUS
servers out there..

-- 
Jouni Malinen                                            PGP id EFC895FA