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?
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.
I would be happy to get some more hints :-).
Kind regards,
Andreas
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
