This is a neat one. EAP-TLS is working just fine between an XP supplicant, a Cisco AP1200 WAP running 12.3(4)JA, and FreeRADIUS 1.0.1 (plus a patch to allow multiple root CAs for EAP-TLS trust). Client certificates are on smartcards, and the AP has a reauthentication timer set, with the intent that clients will be kicked off the WLAN (eventually) when the card is removed (since without the card reauthentication can't complete). Only it doesn't seem to work that way. What appears to happen is this: The authentication starts but never completes, since the client can't complete the TLS handshake without the smartcard inserted (and PIN entered). FreeRADIUS blocks at the "Requiring client certificate" step, as I would expect. However, the AP holds the authentication pending but *leaves the client fully connected*. This means that as long as an incomplete reauthentication is pending, a previously-authenticated client remains online. Not the effect I was looking for. The Cisco AP has an optional setting for RADIUS timeout, but this only seems to apply for the initial packet; since the RADIUS server responded to the initial access-request, that timeout doesn't apply. I tried ramping down max_request_time and setting delete_blocked_requests to yes, but it didn't have any effect; FreeRADIUS never sends an access-reject. There appear to be no controls on XP to force a complete deauthentication after a timeout that I can find. Will porting forward to current rev address this, or does anyone else have an insight? -- Tim