reauth-problem with WPA2-tls

[Andreas Hartmann]

Alan DeKok schrieb:
> Andreas Hartmann wrote:
>> In eap.conf, the option eap -> tls -> cache -> enable is switched off
>> and fast_reauth in wpa_supplicant is enabled.
> 
>   Uh... that makes no sense.

Yes, you're right - I meant option eap -> tls -> cache -> enable is
switched _on_ and fast_reauth is on too on the supplicant. My wrong :-(.

You can see it at this log entry at the initial login:
Wed Jun  2 20:29:14 2010 : Info: [tls] Adding user data to cached session
Wed Jun  2 20:29:14 2010 : Info: [tls] Saving response in the cache
Wed Jun  2 20:29:14 2010 : Info: [tls] WARNING: No information to cache:
session caching will be disabled for this session.

And then the reauth:

Wed Jun  2 20:39:18 2010 : Info: [tls] Retrieved session data from
cached session
Wed Jun  2 20:39:18 2010 : Info: [tls] WARNING: No information in cached
session!
Wed Jun  2 20:39:18 2010 : Info: [eap] Freeing handler
Wed Jun  2 20:39:18 2010 : Info: ++[eap] returns reject
Wed Jun  2 20:39:18 2010 : Info: Failed to authenticate the user.
Wed Jun  2 20:39:18 2010 : Auth: Login incorrect: [myuser at mydom] (from
client WAP610N port 0 cli 00-13-...)
Wed Jun  2 20:39:18 2010 : Info: Using Post-Auth-Type Reject
Wed Jun  2 20:39:18 2010 : Info: +- entering group REJECT {...}
Wed Jun  2 20:39:18 2010 : Info: [attr_filter.access_reject]    expand:
%{User-Name} -> myuser at mydom
Wed Jun  2 20:39:18 2010 : Debug:  attr_filter: Matched entry DEFAULT at
line 11
Wed Jun  2 20:39:18 2010 : Info: ++[attr_filter.access_reject] returns
updated
Wed Jun  2 20:39:18 2010 : Info: Delaying reject of request 13 for 1 seconds
Wed Jun  2 20:39:18 2010 : Debug: Going to the next request
Wed Jun  2 20:39:18 2010 : Debug: Waking up in 0.9 seconds.
Wed Jun  2 20:39:19 2010 : Info: Sending delayed reject for request 13
Sending Access-Reject of id 55 to 192.168.1.9 port 2048
        EAP-Message = 0x040c0004
        Message-Authenticator = 0x00000000000000000000000000000000


It's strangely, that the supplicant couldn't be authorized but the AP
doesn't lock the connection anyway :-). I would have resoected, that the
connection would have been locked afterwards. Instead of, the supplicant
reauths from now on every minute, using this broken fast reauth.

If I do a full reauthentication, the authentication succeeds, but I'm
getting locked anywhere - that makes no sense to me.

>> If fast_reauth in wpa_supplicant is disabled, the reauthentication >>
works fine, but the connection between the AP and the supplicant ist
>> interrupted for about 20 seconds - much to long :-).
>>
>>
>> Do you have any idea how to solve this problem?
>
>   Find out why the supplicant is taking 20s for authentication.

How much time should be ok for the full reauthentication?

I traced the authentication and could see, that the part with the
radiusserver takes less than a second. Most of the time is needed until
the AP sends the new keys for the encryption of the session.
Ok, sometimes it's a little bit faster (9 seconds).


Thanks for your help,
Andreas