On Wed, 24 May 2006, Alan DeKok wrote:
Blame the client.
I'm blaming the AP(s) now. Why is 1x/WPA so badly implemented across the board ? Clients, APs etc., everything. It just does not work. This is just one bad example of many I've come across with 1x/WPA.
The client *should* send an EAP-NAK, and request PEAP. I see this when I use eapol_test, which is based on wpa_supplicant.
Yes, same build set of wpa_supplicant and eapol_test - eapol_test is fine, wpa_supplicant doesn't work EAP: EAP entering state RECEIVED EAP: Received EAP-Request method=19 id=4 EAP: EAP entering state GET_METHOD EAP: Building EAP-Nak (requested type 19 not allowed) EAP: allowed methods - hexdump(len=1): 21 EAP: EAP entering state SEND_RESPONSE EAP: EAP entering state IDLE EAPOL: SUPP_BE entering state RESPONSE EAPOL: txSuppRsp EAPOL: SUPP_BE entering state RECEIVE And nothing. RADIUS doesn't get the NAK. I can only presume the AP is losing it. Sigh. Though it's interesting how I'm getting the exact same problem on two very different APs, an old Netgear ME103 and a Safecom SWBAR-5400. The client is using a Netgear Prism2 based card running hostap. Ok, I've got to re-think this one, using hints how do I force a different "default" EAP-Type, say based on IP ? I've tried DEFAULT Client-IP-Address == "x.x.x.x" EAP-Type := EAP-TTLS "EAP-Type := EAP-TTLS" gets put in auth-detail, so it's getting added, but the supplicant is still getting a response back for the wrong type and trying to do a NAK.