Hi, Yesterday, I moved a fair chunk of our on-site wireless to FreeRADIUS as we migrate from our NPS servers. I have had a number of complaints of users being forced to reauthenticate (prompted for their password again) on odd occasions throughout the day. Logs show a login incorrect: Tue Apr 12 15:06:47 2016 : Auth: (264236) Login OK: [xxx@kent.ac.uk] (from client cwlc-tlb port 2 cli a8:66:7f:12:a9:b9) .....output cut...... Tue Apr 12 15:14:48 2016 : Warning: rlm_ldap (ldap): 2 of 2 connections in use. You probably need to increase "spare" Tue Apr 12 15:14:48 2016 : Error: rlm_ldap (ldap): Cannot open new connection, connection spawning already in progress Tue Apr 12 15:14:48 2016 : Auth: (281194) Invalid user: [xxx@kent.ac.uk] (from client cwlc-tlb port 2 cli a8:66:7f:12:a9:b9 via TLS tunnel) Tue Apr 12 15:14:48 2016 : Auth: (281195) Login incorrect (eap: Failed continuing EAP PEAP (25) session. EAP sub-module failed): [xxx@kent.ac.uk] (from client cwlc-tlb port 2 cli a8:66:7f:12:a9:b9) Tue Apr 12 15:14:48 2016 : Info: rlm_ldap (ldap): Deleting connection (40122) Tue Apr 12 15:14:48 2016 : Info: rlm_ldap (ldap): 2 of 2 connections in use. Need more spares It looks like it is rejecting the auth because it can not make the LDAP connection to validate the user. Two questions on this. First, is it possible to allow clients a couple of attempts to retry their authentication before completely rejecting and forcing them to enter their password again? Second, are there any rules of thumb regarding setting min, max and spare for LDAP connections? At the moment I have: pool { start = 16 min = 8 max = ${thread[pool].max_servers} spare = 16 uses = 0 lifetime = 0 idle_timeout = 0 } When starting with radiusd -x, that gives: rlm_ldap (ldap): Initialising connection pool pool { start = 16 min = 8 max = 32 spare = 16 uses = 0 lifetime = 0 cleanup_interval = 30 idle_timeout = 0 retry_delay = 1 spread = no } Comments in the file suggests it is not sensible to push max any higher. Is it sensible to set spare to 32, or is that setting it the wrong way round? Thanks Dave Hartburn