Hi Dax, I don't know if I can help much here except to cast a second pair of eyes over this - but as you seem to be running short of places to look ...
On Saturday 13 April 2002 12:51, Dax Kelson wrote: > On Fri, 8 Feb 2002, Lutz Jaenicke wrote: > > On Fri, Feb 08, 2002 at 01:53:11AM -0700, Dax Kelson wrote: > > > sshd/ftpd/telnetd -> pam_ldap -> libldap -> libssl/libcrypto > > > > > > To recap, when my dual processor Pentium III is idle, I *always* get a > > > return value of 0 from SSL_connect. If I bog down the box, I get "1" > > > and everything works (login sucessful). [snip] > I took a closer look at this second TCP session with tethereal. > > Here is it: > > 10.1.0.57 is the client, 10.1.0.3 is the server > > 41 6.488846 10.1.0.57 -> 10.1.0.3 TCP 33041 > 389 [SYN] > Seq=2664529133 Ack=0 Win=5840 Len=0 42 6.489711 10.1.0.3 -> 10.1.0.57 > TCP 389 > 33041 [SYN, ACK] Seq=3888408187 Ack=2664529134 Win=16384 Len=0 > 43 6.489753 10.1.0.57 -> 10.1.0.3 TCP 33041 > 389 [ACK] > Seq=2664529134 Ack=3888408188 Win=5840 Len=0 44 6.491937 10.1.0.57 -> > 10.1.0.3 LDAP MsgId=1 MsgType=Extended Request 45 6.495114 > 10.1.0.3 -> 10.1.0.57 LDAP MsgId=1 MsgType=Bad message type (24) 46 > 6.495155 10.1.0.57 -> 10.1.0.3 TCP 33041 > 389 [ACK] Seq=2664529165 > Ack=3888408202 Win=5840 Len=0 47 6.495470 10.1.0.57 -> 10.1.0.3 > LDAP Invalid LDAP packet 48 6.497238 10.1.0.3 -> 10.1.0.57 TCP 389 > > 33041 [FIN, ACK] Seq=3888408202 Ack=2664529289 Win=17396 Len=0 50 > 6.529037 10.1.0.57 -> 10.1.0.3 TCP 33041 > 389 [ACK] Seq=2664529289 > Ack=3888408203 Win=5840 Len=0 I notice that the second connection is terminated pretty much immediately by the server as far as the SSL layer is concerned. Ie. there's a client hello, then nothing else, yet your tethereal output is interlaced with some LDAP debugging messages, one is the server sending a "Bad message type" message to the client and the client sending a "LDAP Invalid LDAP packet" message back to the server?? How is it possible that LDAP messages are being exchanged when the second ssldump output doesn't show *any* payload moving across the wire? Whatever the explanation, the presence of error messages at the LDAP level (however that relates to the SSL stream) suggests that perhaps the disconnection is caused by LDAP error handling? Perhaps if this problem is timing related, the race occurs in how the LDAP protocol logic is flowing rather than in the SSL implementation. But as I say - I can't even follow how SSL and LDAP are being interlaced like that - why are there LDAP messages flowing whilst the second SSL stream hasn't got further than a client hello? Could it be LDAP messages from the inside the first SSL connection/stream are printf()ing at the same time as the second SSL stream is still trying to get up and running? Perhaps that's the "race" here - LDAP (in the first instance) isn't waiting for the second connection to be running properly? I'll simply leave it there for now - those LDAP messages (two of which seem to indicate problems) are enough to make me wait before trying to sift through the SSL tracing :-) Cheers, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
