"error in SSLv3 flush data" when connecting from network

[Antonis Christofides <anthony@itia.ntua.gr>]

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.