Mon Dec 13 07:02:02 2004 : Info: rlm_eap_tls: Length Included Mon Dec 13 07:02:02 2004 : Error: TLS_accept:error in SSLv3 read client certificate A Mon Dec 13 07:02:02 2004 : Info: rlm_eap_tls: Received EAP-TLS ACK message
That is not a show stopper. TLS is complaining about the client certificate you don't need for PEAP, but should process the request anyway. Examine the debug output to see if there is any other failure.
I am trying to connect to a Cisco AP1200 from a Windows XP SP2 client. The client has Network Authentication Open, Data Encryption WEP, EAP Type Protected EAP (PEAP), Authentication Method: Secured password (EAP-MSCHAP v2).
Why open and WEP? Why not WPA TKIP? The AP and supplicant should support this.
No reason. I have changed the configuration to WPA/TKIP. Here is the degub output from radiusd after I have applied the MS hotfix as referenced in a previous message and have changed the AP and client configuration to WPA/TKIP.
--- Walking the entire request list ---
Cleaning up request 22 ID 236 with timestamp 41bdb896
Nothing to do. Sleeping until we see a request.
rad_recv: Access-Request packet from host 10.0.1.231:21646, id=237, length=134
User-Name = "twinders"
Framed-MTU = 1400
Called-Station-Id = "0012.7f75.d940"
Calling-Station-Id = "0090.4b65.34a5"
Service-Type = Login-User
Message-Authenticator = 0xdc3d497356c2a583f2eaf7954c684d3a
EAP-Message = 0x0201000d017477696e64657273
NAS-Port-Type = Wireless-802.11
NAS-Port = 512
NAS-IP-Address = 10.0.1.231
NAS-Identifier = "sub-ap1"
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 23
modcall[authorize]: module "preprocess" returns ok for request 23
modcall[authorize]: module "chap" returns noop for request 23
modcall[authorize]: module "mschap" returns noop for request 23
modcall[authorize]: module "digest" returns noop for request 23
rlm_realm: No '@' in User-Name = "twinders", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 23
rlm_eap: EAP packet type response id 1 length 13
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module "eap" returns updated for request 23
users: Matched entry DEFAULT at line 152
modcall[authorize]: module "files" returns ok for request 23
modcall: group authorize returns updated for request 23
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 23
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 23
modcall: group authenticate returns handled for request 23
Sending Access-Challenge of id 237 to 10.0.1.231:21646
EAP-Message = 0x010200061920
Message-Authenticator = 0x00000000000000000000000000000000
State = 0xe2c50ab039bff81ff87783b7c4dc1736
Finished request 23
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 23 ID 237 with timestamp 41bdb8b7
Nothing to do. Sleeping until we see a request.
I see where it matches the DEFALT entry in the users file. This is simply:
DEFAULT Auth-Type = System
Fall-Through = 1I am trying to authenticate to the /etc/passwd file on the system. Dial up PPP users are able to connect and authenticate OK using the default Framed-User service type:
DEFAULT Service-Type == Framed-User
Framed-IP-Address = 255.255.255.254,
Framed-MTU = 576,
Service-Type = Framed-User,
Fall-Through = YesPerhaps the problem is here? I am new to freeradius and may have missed something here.
--
Tim Winders Associate Dean of Information Technology South Plains College Levelland, TX 79336
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
