1:08 a.m.
>> Tero Saarni <tero.saarni(a)est.tech> schrieb am
01.12.2020 um 09:20 in
Nachricht
<HE1P189MB0491BEEEFFF202642C4145A988F40(a)HE1P189MB0491.EURP189.PROD.OUTLOOK.COM>:
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.
OK, I don't know about the allowable range of the timeout and the scale of
problem you are having, but we had idle connections that were inactive for days
or weeks, so we set the timeout to one day. That worked.
Considering that a closed connection may stay around for several seconds, a
timeout of 5 seconds seems extremely short to me, however.
Regards,
Ulrich
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/ba...
dap/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
1:16 a.m.
New subject: Antw: [EXT] LDAP proxy backend does not drop idle connections
Ulrich Windl wrote:
OK, I don't know about the allowable range of the timeout and the
scale of
problem you are having, but we had idle connections that were inactive for days
or weeks, so we set the timeout to one day. That worked.
Considering that a closed connection may stay around for several seconds, a
timeout of 5 seconds seems extremely short to me, however.
Sure, it is short and it was just for my test case, not for production. The original
problem was found with 5 minute idle timeout, which we wanted to use for production.
However, I do not see any evidence in the code that it would treat these differently, and
what led me to ask here is that I did not manage to spot any code that would set timers
that even could expire in idle conditions. I wonder if something else have happening
within the one-day mark which then triggers disconnect?
--
Tero
________________________________
From: Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>
Sent: Tuesday, December 1, 2020 11:08
To: Tero Saarni <tero.saarni(a)est.tech>; openldap-technical(a)openldap.org
<openldap-technical(a)openldap.org>
Subject: Re: Antw: [EXT] LDAP proxy backend does not drop idle connections
>> Tero Saarni <tero.saarni(a)est.tech> schrieb am
01.12.2020 um 09:20 in
Nachricht
<HE1P189MB0491BEEEFFF202642C4145A988F40(a)HE1P189MB0491.EURP189.PROD.OUTLOOK.COM>:
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.
OK, I don't know about the allowable range of the timeout and the scale of
problem you are having, but we had idle connections that were inactive for days
or weeks, so we set the timeout to one day. That worked.
Considering that a closed connection may stay around for several seconds, a
timeout of 5 seconds seems extremely short to me, however.
Regards,
Ulrich
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/ba...
dap/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
1025
days inactive
1025
days old
openldap-technical@openldap.org
1 comments
2 participants
participants (2)
-
Tero Saarni -
Ulrich Windl