On Fri, 2002-04-12 at 22:30, Geoff Thorpe wrote: > > Can you get any log messages from the server as to "errors" it is reporting > at the time these connections are being dumped that are *not* reported when > the connections are going OK? It could be a race condition above the LDAP > layer, or inside it (above the SSL layer) - and it might also turn out to be > associated with the first connection/stream rather than the second. (Though > knowing nothing about the application in question, it's difficult to know > what the relationship between those two are - different threads?) Either way, > it looks like the "decision" to break ties is made at the server, so that's > probably where you should look to for clues as to why.
I will see if I can dig something up. The server is OpenLDAP 2.0.22 running on NetBSD-1.5.2 mips. NetBSD-1.5.2 seems to come with openssl 0.9.5a, OpenLDAP is linked against that openssl. The clients are Red Hat Linux 7.2 boxes. I'm using nss_ldap and pam_ldap to have my user database and authentication performed out of LDAP. The clients have openssl 0.9.6b and I've also tried 0.9.7c. I'm doing starttls between the clients and server. When logging in nss_ldap makes the first LDAP over TLS connection to verify my user exists, and then when I supply my password pam_ldap makes the second LDAP over TLS to check my password. This second one is the one that fails. I have about 20 clients that have ~500Mhz cpus and everything works perfectly. On about 15 clients with 1700Mhz cpus, the second pam_ldap connection fails *unless* I bog down the client machine. Another clue. When I turn off nss_ldap and have my user account listed in /etc/passwd,/etc/group, but *still* use pam_ldap to get perform the password checking out of the LDAP server, it works! Dax ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
