[email protected] 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? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
