According to the docs: "Once EAP-Identity response is received by the server, based on the default_eap_type, the server will send a new request (MD5-Challenge request incase of md5, TLS-START request incase of tls) to the supplicant. If the supplicant is rfc2284 compliant and doesnot support the EAP-Type sent by the server then it sends EAP-Acknowledge with the supported EAP-Type. If this EAP-Type is supported by the server then it will send the respective EAP-request." But I can't get it to work ! I want to be able to support PEAP and TTLS. I set a default_eap_type of peap or ttls and a client (wpa_supplicant or Windows XP+SecureW2) can authenticate using that default type. But if I try to authenticate not using the default type it fails - the above described mechanism doesn't seem to kick in. What am I doing wrong ? [default type of ttls, trying to authenticate with peap using wpa_supplicant] rad_recv: Access-Request packet from host 10.1.1.7:1812, id=134, length=176 User-Name = "x@x" Cisco-AVPair = "ssid=x" NAS-IP-Address = 10.1.1.7 Framed-MTU = 1400 Called-Station-Id = "x" Calling-Station-Id = "x" NAS-Identifier = "DINKITCH" NAS-Port = 37 NAS-Port-Type = Wireless-802.11 Service-Type = Login-User EAP-Message = 0x020100150174657374406c696c79686f7070696e67 Message-Authenticator = 0x8f0581d54ae3940c3e9b0bf7bd1297ad Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 radius_xlat: '/usr/local/var/log/radius/radacct/10.1.1.7/auth-detail-20060524' rlm_detail: /usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /usr/local/var/log/radius/radacct/10.1.1.7/auth-detail-20060524 modcall[authorize]: module "auth_log" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_eap: EAP packet type response id 1 length 21 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 0 modcall[authorize]: module "files" returns notfound for request 0 radius_xlat: 'x@x' rlm_sql (sql): sql_set_user escaped user --> 'x@x' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE Username = 'x@x' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 4 radius_xlat: 'SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'x@x' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE Username = 'x@x' ORDER BY id' radius_xlat: 'SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'x@x' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id' rlm_sql (sql): Released sql socket id: 4 modcall[authorize]: module "sql" returns ok for request 0 modcall: leaving group authorize (returns updated) for request 0 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 0 modcall: leaving group authenticate (returns handled) for request 0 Sending Access-Challenge of id 134 to 10.1.1.7 port 1812 EAP-Message = 0x010200061520 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xfedb2ff2bb0d24ab41c48f3ab7eba8b9 Finished request 0 Going to the next request And that is that, the client claims authentication has failed.
gARetH baBB <hick.freeradius@gink.org> wrote:
"Once EAP-Identity response is received by the server, based on the default_eap_type, the server will send a new request (MD5-Challenge request incase of md5, TLS-START request incase of tls) to the supplicant. If the supplicant is rfc2284 compliant and doesnot support the EAP-Type sent by the server then it sends EAP-Acknowledge with the supported EAP-Type. If this EAP-Type is supported by the server then it will send the respective EAP-request."
But I can't get it to work !
Blame the client.
[default type of ttls, trying to authenticate with peap using wpa_supplicant] ... And that is that, the client claims authentication has failed.
The client *should* send an EAP-NAK, and request PEAP. I see this when I use eapol_test, which is based on wpa_supplicant. In any case, RADIUS is driven by the client. If the server sends a packet and the client doesn't "respond", it means that the client has decided to stop talking to the server. Alan DeKok.
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.
gARetH baBB <hick.freeradius@gink.org> wrote:
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
See "man 5 users". You're setting EAP-Type as a reply, not a check item. You're also forcing TTLS *inside* of the TTLS tunnel, which is wrong. You want: DEFAULT Client-Ip-Address == 1.2.3.4, FreeRADIUS-Proxied-To !* 127.0.0.1, EAP-Type := EAP-TTLS Alan DeKok.
participants (2)
-
Alan DeKok -
gARetH baBB