Problem solved!
It's the server certificate problem.
I re-generated the server certificate and keep the client and root certificates the
same. The problem is gone. I was
using Ken Roser's script (section 9 in HOWTO: EAP/TLS Setup for FreeRADIIUS and
Wiindows XP Supplliicant Version 1.0.1
April 18, 2002) to generate all certificates (root, server and client). Since I
encounter this "rlm_eap_tls: Invalid ACK
received", the other day I used the script in Raymond McKay's HOWTO
(http://www.impossiblereflex.com/8021x/eap-tls-HOWTO.htm#6) to generate a new client
(kevin) certificate and the problem
still persisted. Today, I use Raymond McKay's script generate a new server certificate
and problem solved!
I guess that the problem was when the old server certificate was sent to client, the
client was not able to verify the
server certificate and then the authentication link was broken. Why the old server
certificate fail to be verified by
client? no clue. Since I haven't changed root CA certificate since day one and now it
works! To further verify that it
was caused by the old server certificate, I disable the "Validate server certificate"
check box under "Smart Card or
other Certificate Properties" and use the old server certificate and then it works.
Case closed.
-Paul
------------------------------------------------------------------------------------
hmmm, it's going too far for me :)
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
End of Freeradius-Users Digest
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
