On Mon, 10 Nov 2003, Kostas Kalevras wrote:
> OK that one was a typo. I was actually referring to cbtls_msg() function in cb.c
> which is never called. And now that i think of it (and read the EAP-TLS RFC):
>
> EAP-Message = 0x021100061500
>
> So we do get an EAP-TLS Fragment ACK. But the callback function will *never* get
> called for a packet like this (it isn't an actual TLS segment in any case). As a
> result i don't think that the checks run in the eaptls_ack_handler() function
> can actually work. I 've removed them and now the TTLS session works much better
> (i do get a core dump just before sending back the Access-Accept but i 'll
> probably figure that one out).
For the core dump now:
Loaded symbols for /usr/libexec/ld-elf.so.1
#0 0x2844b337 in eaptls_gen_mppe_keys (reply_vps=0x81169b8, s=0x809ec00,
prf_label=0x14 <Address 0x14 out of bounds>)
at mppe_keys.c:136
136 memcpy(p, s->s3->client_random, SSL3_RANDOM_SIZE);
(gdb) print s
$1 = (struct ssl_st *) 0x809ec00
(gdb) print s->s2
$2 = (struct ssl2_state_st *) 0x8117400
(gdb) print s->s3
$3 = (struct ssl3_state_st *) 0x0
In other words the s->s3 structure is NULL. I 've added a few debug statements
in rlm_eap_tls and rlm_eap_ttls and it seems to always be NULL. I don't know why
though. In any case that one is causing the core dumps. If there are no
objections i can add a few checks in eaptls_gen_mppe_keys() and
eapttls_gen_challenge() for s->s3 being NULL
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
