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.
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? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed state Open to Feedback
Dne čtvrtek 24 září 2009 22:19:40 Howard Chu napsal(a): > 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) > > > 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. I'm not sure I have much more explicit information for you. I'm sending certificate in attachment. It's a self signed testing certificate I generated on my system. I'm also sending you slapd.conf with relevant information and CA bundle file. If you need anything else, just let me know. Just for complete information: I tried slapd on Fedora 12 and RHEL 5.3 (x86_64) and on Ubuntu 9.04 (i386). On each system I used different self signed certificate. In both cases attached slapd.conf file was used. To reproduce error, I just started the slapd service (slapd -h 'ldaps:///' -u ldap) with given config file and connected to it. When I tried to connect with openssl s_client -connect fedora12-64, I received this output (and then freeze): CONNECTED(00000003) depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny@redhat.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny@redhat.com verify return:1 > 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? I believe what is stated there is that hangs don't occur with -d2, but they do with -d1 (not -d -1). I can also confirm this behaviour, that with -d1 hangs occur, but with -d2 they don't. (or at least I didn't encounter them during my testing). Hopefully I provided some useful information. Regards -- Jan Zeleny Associate SW Engineer, BaseOS Team Brno, Czech Republic
Jan Zelený wrote: > Dne čtvrtek 24 září 2009 22:19:40 Howard Chu napsal(a): >> 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) >>> >> 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. > I'm not sure I have much more explicit information for you. I'm sending > certificate in attachment. It's a self signed testing certificate I generated on > my system. I'm also sending you slapd.conf with relevant information and CA > bundle file. If you need anything else, just let me know. > > Just for complete information: > I tried slapd on Fedora 12 and RHEL 5.3 (x86_64) and on Ubuntu 9.04 (i386). On > each system I used different self signed certificate. In both cases attached > slapd.conf file was used. To reproduce error, I just started the slapd service > (slapd -h 'ldaps:///' -u ldap) with given config file and connected to it. When > I tried to connect with openssl s_client -connect fedora12-64, I received this > output (and then freeze): > > CONNECTED(00000003) > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny@redhat.com > verify error:num=18:self signed certificate > verify return:1 > depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech > s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny@redhat.com > verify return:1 > > >> 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? > > I believe what is stated there is that hangs don't occur with -d2, but they do > with -d1 (not -d -1). I can also confirm this behaviour, that with -d1 hangs > occur, but with -d2 they don't. (or at least I didn't encounter them during my > testing). > > Hopefully I provided some useful information. Thanks, that helped, a fix is now in CVS HEAD. I should point out that the configuration used to reproduce this problem is quite a poor one. As the OpenLDAP Admin Guide clearly states, your server should only be configured with the CA certs for which it will accept client certs. Your ca-bundle.crt file is 670KB and loaded with a lot of CAs that are irrelevant; it's when slapd sends the client its list of acceptable CAs that the connection was getting jammed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Feedback to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
changed notes changed state Release to Closed
fixed in HEAD fixed in RE24