On Fri, Apr 12, 2002 at 11:38:34PM -0600, Dax Kelson wrote:
> 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!
Your ssldump output is missing the cleartext negotiation including the
STARTTLS command (there is a switch to make ssldump also show this part).
I however doubt it will lead us anywhere.
The analysis so far pretty much shows, that the server is closing down
the connection. I must admit that I did not work with OpenLDAP, yet.
Is OpenLDAP a multithreaded application? It might be possible that they have
a race condition that leads to problems when a new connection is coming in
from some host, while the old connection is not yet considered closed...
Anyway we would need the output and error messages from the LDAP server.
The ssldump output indicates that a new connection is attempted all the time,
so that there should be no problem with session resumption.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
