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.
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.
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. At this point, the only thing I can suggest is to put a packet capture on the net somewhere. That might give more information. Alan DeKok.