Thanks for the response. See below: ----- Original Message ----- From: Alan DeKok <aland@ox.org> Date: Friday, August 5, 2005 11:03 am Subject: Re: Multiple Password Prompts

ragan_davis@colstate.edu wrote:

...

As I'm troubleshooting this, I generated another question in my head. This time I'll give some freeradius debug (see blocks between "*********"):

Here's an exerpt from first try (failure): ... Sending Access-Challenge of id 186 to 192.168.3.2:1024

That doesn't look like a failure to me. The supplicant may stop talking to the server, and start a new session, but the server thinks everything's OK.

Sorry...maybe I used the wrong word. By "failure", I meant that from the end user's perspective, the first attempt was a failure. If the server get's an incomplete reply to it's challenge, or no reply, will it resend it's challenge? Or, will the client sense that the server didn't respond to it's challenge response and start a new session. I ask because, in talking to the vendors, there is a question of which side is giving up, or which side isn't sending complete requests/responses. Of course, because each vendor has their own radius server and 802.1x client solution, they want to blame freeradius so that I'll buy their product. I'm trying my hardest to fight this, because I'm a big freeradius fan. The debug on the Odyssey Client shows that it believes it sent the response to the challenge. The debug on the WLAN switch shows that it forwards both the challenge from freeradius and the challenge response from the client. Freeradius debug appears to get the response from the client, sees the outer credentials (anonymous, etc.), but doesn't process the tunneled information for some reason.

...

I looked back through some of the output, and it seems that each time it fails I get "eaptls_process returned 13", but when it is succeeds I get "eaptls_process returned 7". Anyone know what 7 and 13 represent (please don't say 'sucess' or 'failure'...i'm hoping it more meaningful than that).

From src/modules/rlm_eap/types/rlm_eap_tls.h:

typedef enum { EAPTLS_INVALID = 0, /* invalid, don't reply */ EAPTLS_REQUEST, /* request, ok to send, invalid to receive */ EAPTLS_RESPONSE, /* response, ok to receive, invalid to send */ EAPTLS_SUCCESS, /* success, send success */ EAPTLS_FAIL, /* fail, send fail */ EAPTLS_NOOP, /* noop, continue */ EAPTLS_START, /* start, ok to send, invalid to receive */ EAPTLS_OK, /* ok, continue */ EAPTLS_ACK, /* acknowledge, continue */ EAPTLS_FIRST_FRAGMENT, /* first fragment */ EAPTLS_MORE_FRAGMENTS, /* more fragments, to send/receive */ EAPTLS_LENGTH_INCLUDED, /* length included */ EAPTLS_MORE_FRAGMENTS_WITH_LENGTH, /* more fragments with length */ EAPTLS_HANDLED /* tls code has handled it */ } eaptls_status_t;

So I don't see any particular reason why one session would succeed and the other would fail.

So, does this mean that I should interpret the above enum to have elements 0-13, or 1-14, and match the numbers 7 and 13 with it's position in the enum?

...

Also, anyone know what the rlm_eap_tls messages mean that accompany the 'returned 13' block?

Information about internal TLS stuff. There are a *lot* of TLS packets that go back and forth.

I'm curious why we can see the TLS stuff during the first try (13), but not the second try (7). What is the difference? I agree...it seems like there should nothing different between what the client sends in the first try and the second.

At this point, the only thing I can suggest is to put a packet capture on the net somewhere. That might give more information.

I performed a packet capture using ethereal, listening on the interface that freeradius is running on. Did this on the box, not inline. I would rather not post it to the list, but I'd be glad to send it to you if you'd be willing to look at it. Let me know.

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html