Multiple EAP types
hick.freeradius at gink.org
Wed May 24 18:14:38 CEST 2006
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: 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 ?
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.
More information about the Freeradius-Users