jzeleny@redhat.com wrote:
Full_Name: Jan Zeleny Version: 2.4.18 OS: Fedora 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.40.79.66)
Following bug report is a good introduction to the issue: https://bugzilla.redhat.com/show_bug.cgi?id=509230
I managed to reproduce it simply by turning on TLS and setting TLSVerifyClient allow. In that configuration local connections to ldaps still work, but connections from remote machines don't work in about 80-90% cases.
I tried to trace the bug, so far I found that when using this option, slapd sends it's certificate to TCP socket and gets the EAGAIN in the middle of writing. After that it goes to epoll_wait and there it waits indefinitely. I suspect the EAGAIN happens because TCP socket is full or something like that. Notice that when you turn on debugging information about packet handling, this issue disappears - maybe socket has time to get empty?
I tried and confirmed the bug in several versions of openldap (incl. 2.4.18) and several Linux distributions to eliminate the possibility this issue is caused by some other component or it was solved already.
I'm unable to reproduce this using slapd on a debian x86-64 system, whether on the local LAN or from 13 hops away. I've also used the tcp-buffer option to set a minimum sized socket buffer and still could not duplicate the problem. You will need to provide more explicit information on how to reproduce this issue. Perhaps providing a set of CA/server certs will also be necessary.
Please note that the bug report you reference (509230) gives inconsistent information; it says that no hang occurs with -d2, but that hangs occur with no diagnostics, even with -d -1. Obviously -d -1 includes -d 2, so: does it hang, or not, with -d -1?