perhaps you should try to ask this at the development list. i have no idea why freeradius considers the incoming ACK being malformed. my AP350 doesn't do that, the 340 neither and i've never heard of it before, sorry.
do you want to downgrade to some not-beta version of the firmware? i really don't know if it will help. if you find an answer, you are welcome to distribute it here.
ciao
artur
ps when sending ethereal files, please consider sending those as attachments in ethereal format, not just text dump. it's much easier to read in the ethereal window.
Ynjiun P. Wang wrote:
Regarding the problem of:
"rlm_eap_tls: Received EAP-TLS ACK message
rlm_eap_tls: Invalid ACK received
modcall[authenticate]: module "eap" returns invalid"
I trace the code using ddd. I manipulate the fragment_size = 256, 512, 1210 etc. to observe the behaviour of the
eaptls_ack_handler code below. I found that it runs well until the last fragment which the
tls_session->info.handshake_type == certificate_request /*13*/ and
tls_session->fragment == 0 and then it broke. If the server EAP message is 1107, and if sed fragment_size = 512 in
radiusd.conf then I would get (type, fragment) pair in this routing 3 times: (13, 1), (13, 1) and (13, 0). The first two
times the Radius response nicely:
"rlm_eap_tls: Received EAP-TLS ACK message
modcall[authenticate]: module "eap" returns ok"
and the last (13, 0) response:
"rlm_eap_tls: Received EAP-TLS ACK message
rlm_eap_tls: Invalid ACK received
modcall[authenticate]: module "eap" returns invalid"
Is the (13, 0) a normal ending of certificate_request? what causing this abnormal ending if this is not normal?
/*********************code excerpt from eap_tls.c**********************/
eaptls_status_t eaptls_ack_handler(EAP_HANDLER *handler)
{
tls_session_t *tls_session;
tls_session = (tls_session_t *)handler->opaque;
if ((tls_session == NULL) || (tls_session->info.origin == 0)) {
radlog(L_ERR, "rlm_eap_tls: Unexpected ACK received");
return EAPTLS_NOOP;
}
switch (tls_session->info.content_type) {
case alert:
eaptls_fail(handler->eap_ds);
session_free(&handler->opaque);
return EAPTLS_FAIL;
case handshake:
if (tls_session->info.handshake_type == finished) {
eaptls_success(handler->eap_ds);
eaptls_gen_mppe_keys(handler->reply_vps,
tls_session->ssl);
session_free(&handler->opaque);
return EAPTLS_SUCCESS;
} else if (tls_session->fragment > 0) {
/* Fragmentation handler, send next fragment */
eaptls_request(handler->eap_ds, tls_session);
return EAPTLS_REQUEST;
}
/*
* For the rest of the conditions,
* switch over to the default section below.
*/
default:
radlog(L_ERR, "rlm_eap_tls: Invalid ACK received");
session_free(&handler->opaque);
return EAPTLS_NOOP;
}
}
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
Artur Hecker Groupe Acc�s et Mobilit�
hecker[at]enst[dot]fr D�partement Informatique et R�seaux
+33 1 45 81 7507 46, rue Barrault 75634 Paris cedex 13
http://www.infres.enst.fr ENST Paris
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
