Ulrich Windl wrote: > It may depend on the version, but for us it worked. How did you check that it > doesn't work?
I have tested by setting up "idassert-bind" configuration which results in cached connection. I set idle-timeout to 5 (seconds). I did packet capture with Wireshark to see that the connection is still up. To test I have executed: 1. execute search from client 2. wait for the duration of idle-timeout to expire 3. observe from LDAP protocol capture that the connection is still up Secondly I tested: 1. execute search from client 2. wait for the duration of idle-timeout to expire 3. execute search from client again 4. observe that unbind and TCP connection tear down happened immediately after step 3 I also tested that search before idle timeout extends the timeout: 1. execute search from client 2. execute search from client again before idle-timeout 3. observe that nothing happens 4. execute search after idle-timeout has passed when measuring the time from step 2. 5. observe that unbind and TCP connection tear down happened immediately after step 4 I also tried to find the function within back-ldap code that compares the idle timeout value. This is the only place in the code I found idle timeout being compared https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/back-ldap/bind.c#L1133 and it is in function ldap_back_getconn(). I attached gdb to slapd and breakpoint to the function. Debugger shows that it does not seem to get called unless there is activity from client to proxy i.e. not during connection from proxy to remote LDAP remains idle. I tested only with recent releases and git master, not with very old versions since they are bit harder to compile with modern distros. But I have compared the code from a random historical release. It seems to be the same as today. Quanah also replied "back-ldap likely needs a task to check for idle connections" so I'm bit puzzled if this has worked previously. Maybe ldap_back_getconn() can be called in some other scenario also without having traffic from client towards the proxy? -- Tero
