guenther+ldapdev@sendmail.com wrote:

Full_Name: Philip Guenther Version: 2.3.27 OS: Linux and Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.58.1.252)

[I vaguely recall seeing a report of this issue in the archives of one of the mailing lists, but I can no longer find the original.]

If you trace the packets sent when you use, for example, ldapsearch against a server on a different host, using either the -Z option to do TLS or using an ldaps URI, you'll discover that the TCP connection is actually reset instead of being closed cleanly: the client sends TCP RSTs in response to the server's final packets.

This is because libldap uses the following sequence when unbind a TLS or SSL connection:

1. send the unbind request (over the TLS or SSL layer)
2. call SSL_shutdown(), sending the TLS close_notify alert
3. call close()

After receiving the close_notify alert from step (2), the server sends back its own close_notify alert and then calls close(). However, because the client didn't wait for the server's response before calling close() on its end, the client's TCP stack considers the TCP connection to already be gone and responds with the RST packets. This occurs with Linux and Solaris clients and probably most other unices: the response to packets after a close() doesn't vary in my experience.

That sounds like you're seeing a bug in the kernel's TCP stack then. A TCP close sends a FIN to the other end and is required to wait for the FIN to be ACK'd before the connection can be torn down. (Subject to 2MSL timeout.) That is most certainly not our problem.