Hello, I'm a bit hazy on "fast reconnect" -- from what I've ready in the list archives and found on various other sites, it uses cached information about the state of the TLS dialogue with the server terminating the EAP connection to reduce the number of messages which must be exchanged as a supplicant authenticates when moving (say) wireless access point. Looking at the FreeRADIUS changes, history it seems support for this was added in 2.1.1 for EAP-TLS (which I assume affects EAP-PEAP and EAP-TTLS, both of which we're using). Would I be right in thinking that, if the cached state is NOT found on the backend RADIUS server (there may be one or more proxies in the way, especially if the user is logging in over eduroam, but I assume that that doesn't matter, as they just proxy things through) that the device authenticating will just start the TLS negotiation from scratch and the user won't notice anything, except maybe a slightly longer time to roam between wireless access points (but, in practice, probably so quick, they won't)? This would also presumably be the case if the next authentication happened to take place against a different backend server at our eduroam 'home' site as there is no way to synchronise these caches. In other words, the only reason to untick the 'Fast reconnect' box on (for example) a Windows machine would be if there was a suspicion that this was either broken, or you wanted to force the full TLS negotiation to restart, as the user moved access points. [Does anyone know of a broken wireless NAS which complains if the full TLS conversation doesn't start from scratch, as you move around.] I'm just trying to see if there's a reason why anyone should NOT tick this box on a supplicant device. We're running FreeRADIUS >2.1.1. Thanks in advance, - Bob -- Bob Franklin <rcf34@cam.ac.uk> +44 1223 748479 Network Division, University of Cambridge Computing Service