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: [myu...@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} -> myu...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html