Andreas Hartmann schrieb: > Bjørn Mork schrieb: >> Andreas Hartmann <andihartm...@01019freenet.de> writes: >> >>> Fri Jun 4 11:22:48 2010 : Info: [tls] WARNING: No information in >>> ^^^^^^^^^^^^^^^^^^^^^^^^^ >>> cached session! >>> ^^^^^^^^^^^^^^^ >>> >>> Fri Jun 4 11:22:48 2010 : Info: [eap] Freeing handler >>> Fri Jun 4 11:22:48 2010 : Info: ++[eap] returns reject >>> Fri Jun 4 11:22:48 2010 : Info: Failed to authenticate the user. >>> Fri Jun 4 11:22:48 2010 : Auth: Login incorrect: [myu...@mydom] (from >>> client WAP610N port 0 cli 00-13-....) >>> Fri Jun 4 11:22:48 2010 : Info: Using Post-Auth-Type Reject >>> Fri Jun 4 11:22:48 2010 : Info: +- entering group REJECT {...} >>> Fri Jun 4 11:22:48 2010 : Info: [attr_filter.access_reject] expand: >>> %{User-Name} -> myu...@mydom >>> Fri Jun 4 11:22:48 2010 : Debug: attr_filter: Matched entry DEFAULT at >>> line 11 >>> Fri Jun 4 11:22:48 2010 : Info: ++[attr_filter.access_reject] returns >>> updated >>> Fri Jun 4 11:22:48 2010 : Info: Delaying reject of request 11 for 1 seconds >>> >>> >>> What does it mean: No information in cached session? Couldn't the key be >>> found (what's the key? The username "myuser" or "myu...@mydom" or >>> soemthing else - do I have the chance to debug it?) or was the key >>> found, but there was no data associated? >> >> I wondered about the same... You can find the session store and >> retrieve code in src/modules/rlm_eap/libeap/eap_tls.c : >> >> } else if (!SSL_session_reused(tls_session->ssl)) { >> RDEBUG2("Saving response in the cache"); >> >> vp = paircopy2(request->reply->vps, PW_USER_NAME); >> pairadd(&vps, vp); >> >> vp = paircopy2(request->packet->vps, PW_STRIPPED_USER_NAME); >> pairadd(&vps, vp); >> >> if (vps) { >> SSL_SESSION_set_ex_data(tls_session->ssl->session, >> eaptls_session_idx, vps); >> } else { >> RDEBUG2("WARNING: No information to cache: session >> caching will be disabled for this session."); >> SSL_CTX_remove_session(tls_session->ctx, >> tls_session->ssl->session); >> } >> >> /* >> * Else the session WAS allowed. Copy the cached >> * reply. >> */ >> >> } else { >> >> vp = SSL_SESSION_get_ex_data(tls_session->ssl->session, >> eaptls_session_idx); >> if (!vp) { >> RDEBUG("WARNING: No information in cached session!"); >> return eaptls_fail(handler, peap_flag); >> } else { >> RDEBUG("Adding cached attributes to the reply:"); >> debug_pair_list(vp); >> pairadd(&request->reply->vps, paircopy(vp)); >> >> /* >> * Mark the request as resumed. >> */ >> vp = pairmake("EAP-Session-Resumed", "1", T_OP_SET); >> if (vp) pairadd(&request->packet->vps, vp); >> } >> } >> >> >> So I guess the warning means that either SSL_SESSION_set_ex_data() or >> SSL_SESSION_get_ex_data() failed. A useful change would be testing the >> return value of SSL_SESSION_set_ex_data() and print a warning if it >> fails, possibly using ERR_get_error() and ERR_error_string() or similar >> to get the actual error. The latter would also be useful in the >> SSL_SESSION_get_ex_data() failure case > > Debugging of SSL_SESSION_set_ex_data() > > The returncode of the function is 1 (don't know, if it should be 0 - but > it could be correct too, if it means, that one pair has been stored). > > vps, which SSL_SESSION_set_ex_data() is given as argument, consists of > one NULL element. > > request->packet->vps->name gives User-Name, request->reply-vps is null > (should be PW_USER_NAME). But there cant be any password, because there > exists no password, because the authentication is done exclusively with > keys. > Could this problem be solved by a configuration entry or must it be > hacked? Is it possible to give wpa_supplicant a dummy password?
Well, SSL_SESSION_set_ex_data-Error: error:00000000:lib(0):func(0):reason(0) - SSL couldn't find an error. > > Debugging of SSL_SESSION_get_ex_data() > > At resuming, Index is 2 (eaptls_session_idx). This would be ok. Seems, > that the returncode 1 from SSL_SESSION_set_ex_data() means, that nothing > has been saved. But: no error has been detected: SSL_SESSION_get_ex_data-Error: error:00000000:lib(0):func(0):reason(0) Now, I looked at the SSL-session_id. tls_session->ssl->session->session_id is empty when the data is saved to the session. At the time the data is fetched from the session during reauth, the session_id is not empty (means: there is another id). I tested to unload the datas after they have been saved - there was no problem! The data could be retrieved again. Could there be a problem with the session-handling? There seem to be different sessions? This would be an explanation why there are no errors while storing or restoring the data. Kind regards, Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html