Multiple EAP types

[gARetH baBB]

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.