Hi,
Summary:
A tls connection between a client and a 2.3.30 slapd hangs while the server is giving the certificate; but this does not happen if the server is run with -d 2 or higher, or if the client is the server itself.
Details:
(A seemingly similar issue has been reported before, without satisfactory reply, 4 years ago: http://www.openldap.org/lists/openldap-software/200210/msg00459.html)
My slapd is the Debian-etch-packaged 2.3.30.
If I run a ldapsearch -ZZ on the server, it runs fine.
If I try to run the same thing from a client through the network, then the connection hangs (I tried this from three clients). After I hit Enter, the client stays there and it appears to wait forever until interrupted.
If I use -d 1 on both the client and the server, then the client hangs after it has displayed
TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 0, subject: /C=GR/L=Athens/O=National Technical University of Athens/OU=ITIA Research Team/CN=www.itia.ntua.gr/emailAddress=sysadmins@itia.ntua.gr, issuer: /C=GR/L=Athens/O=National Technical University of Athens/OU=ITIA Research Team/CN=www.itia.ntua.gr/emailAddress=sysadmins@itia.ntua.gr TLS trace: SSL_connect:SSLv3 read server certificate A
and the server has displayed
TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write certificate request A TLS trace: SSL_accept:error in SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 flush data
But if I use -d 2 or higher on the server, then the connection succeeds. (Increasing -d on the client does not appear to affect it.)
Could you suggest how to search into it next? Because I'm lost. I thought it might have to do with networking hardware, but ping -f from one client to the server runs fine, with no packet loss, and nfs (which I've noticed to be most sensitive to networking hardware issues) also runs fine. The three clients where through Gigabit, 100 MBits, and 10 MBits. Two of them were running ubuntu-edgy-packaged ldap-utils 2.2.26, one was running debian-etch-packaged 2.3.30. All had identical behaviour.