Alan, Sorry about duplicating my original email. I found your reply about 3 seconds after doing that. Here is the stack trace. Maybe my version of ssl is too old? [mbradley@mars bin]$ openssl OpenSSL> version OpenSSL 0.9.7b 10 Apr 2003 #0 0x402d4a97 in eaptls_gen_mppe_keys (reply_vps=0x8179c08, s=0x8157790, prf_label=0x402da5d9 "ttls keying material") at mppe_keys.c:136 136 memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE); (gdb) bt #0 0x402d4a97 in eaptls_gen_mppe_keys (reply_vps=0x8179c08, s=0x8157790, prf_label=0x402da5d9 "ttls keying material") at mppe_keys.c:136 #1 0x402d8912 in eapttls_authenticate (arg=0x814dcb0, handler=0x81576e8) at rlm_eap_ttls.c:253 #2 0x4002a627 in eaptype_call (atype=0x814dba0, handler=0x81576e8) at eap.c:167 #3 0x4002a9f5 in eaptype_select (inst=0x810fe60, handler=0x81576e8) at eap.c:353 #4 0x40029d89 in eap_authenticate (instance=0x810fe60, request=0x8179b38) at rlm_eap.c:271 #5 0x08054c7a in call_modsingle (component=0, sp=0x810ebe8, request=0x8179b38, default_result=0) at modcall.c:219 #6 0x08054e6e in modcall (component=0, c=0x810ebe8, request=0x8179b38) at modcall.c:344 #7 0x08054d37 in call_modgroup (component=0, g=0x814f3e0, request=0x8179b38, default_result=0) at modcall.c:252 #8 0x08054e1d in modcall (component=0, c=0x814f3e0, request=0x8179b38) at modcall.c:335 #9 0x0805492b in module_authenticate (auth_type=6, request=0x8179b38) at modules.c:891 #10 0x0805198b in rad_check_password (request=0x8179b38) at auth.c:353 #11 0x08051d53 in rad_authenticate (request=0x8179b38) at auth.c:644 #12 0x0804d5a9 in rad_respond (request=0x8179b38, fun=0x8051a9c <rad_authenticate>) at radiusd.c:1642 #13 0x0804d2ea in main (argc=2, argv=0xbffff514) at radiusd.c:1427 #14 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 123 void eaptls_gen_mppe_keys(VALUE_PAIR **reply_vps, SSL *s, 124 const char *prf_label) 125 { 126 unsigned char out[2*EAPTLS_MPPE_KEY_LEN], buf[2*EAPTLS_MPPE_KEY_LEN]; 127 unsigned char seed[64 + 2*SSL3_RANDOM_SIZE]; (gdb) l 128 unsigned char *p = seed; 129 size_t prf_size; 130 131 prf_size = strlen(prf_label); 132 133 memcpy(p, prf_label, prf_size); 134 p += prf_size; 135 136 memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE); 137 p += SSL3_RANDOM_SIZE; (gdb) print s $2 = (SSL *) 0x8157790 (gdb) print s->s3 $3 = (struct ssl3_state_st *) 0x0 Regards, Martin. -----Original Message----- From: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of Alan DeKok Sent: 19 July 2005 20:01 To: FreeRadius users mailing list Subject: Re: FW: TTLS and PAP <martin.p.bradley@bt.com> wrote:
I'm trying to get TTLS/PAP working using freeradius 1.0.4. I must have it configured incorrectly because its giving a Segmentation fault just before giving the Access-Accept & EAP-Success back to the switch. I have searched the archives for a solution but not found help to sort my problem out.
See doc/bugs
I don't understand is why the modcall[authorise] appear often in request processing before modcall[authenticate]. I thought the order was to authenticate a user and then once we are sure they are who they say they are then we authorise them to use the network.
Due to historical issues, FreeRADIUS has pre-authenticate, authenticate, and post-authenticate. The pre-authenticate is called "authorize". The sections could just as easily be called "foo", "bar", and "baz". It makes no difference to the operation of the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
<martin.p.bradley@bt.com> wrote:
Here is the stack trace.
Maybe my version of ssl is too old?
Maybe.
#0 0x402d4a97 in eaptls_gen_mppe_keys (reply_vps=0x8179c08, s=0x8157790, prf_label=0x402da5d9 "ttls keying material") at mppe_keys.c:136 136 memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE);
TRhat doesn't tell me much, unfortunately. Alan DeKok.
Hi there, I am running FreeRADIUS Version 1.0.4 on Solaris 8 for RADIUS services. Then I have a Cisco 3660 configured for inbound https auth-proxy. IOS on router -> c3660-ik9o3s-mz.123-14.T.bin % users <snip> # test Auth-Type := Local, User-Password == "test1234" Service-Type = Outbound, cisco-avpair = "auth-proxy:priv-lvl=15", cisco-avpair += "auth-proxy:proxyacl#1=permit tcp host 12.13.14.15 host 21.31.41.51 eq 22" # Problem: user test get successful auth-prox authorization but the dynamic acl is not used by the router. FYI - The RADIUS server passes the ACL and he router receives the ACL (debug not reported in this email). Can you help me? Thanks a lot. Full debug on the server: # radiusd -X <snip> rad_recv: Access-Request packet from host 131.176.131.40:1645, id=23, length=102 User-Name = "test" Reply-Message = "Password: " User-Password = "test1234" NAS-Port = 226 NAS-Port-Id = "tty226" NAS-Port-Type = Virtual Calling-Station-Id = "xx.xx.xx.xx" NAS-IP-Address = xx.xx.xx.xx Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "adalessa", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry adalessa at line 98 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied User-Password matches local User-Password Sending Access-Accept of id 23 to xx.xx.xx.xx:1645 Cisco-AVPair = "auth-proxy:priv-lvl=15" Cisco-AVPair += "auth-proxy:proxyacl#1=permit tcp host 12.13.14.15 host 21.31.41.51 eq 22" Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 23 with timestamp 42dea17c Nothing to do. Sleeping until we see a request.
Andrea.DAlessandro@esa.int wrote:
Problem: user test get successful auth-prox authorization but the dynamic acl is not used by the router. FYI - The RADIUS server passes the ACL and he router receives the ACL (debug not reported in this email).
Then the router is broken. Alan DeKok.
participants (3)
-
Alan DeKok -
Andrea.DAlessandro@esa.int -
martin.p.bradley@bt.com