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
If I run strace -f -p 'PID of getty', and then login, it works (as I
described before). Here is the (much longer) ssldump output.
10.1.0.57 is the client, 10.1.0.3 is the server
# ssldump -n host 10.1.0.57 and port 389
New TCP connection #1: 10.1.0.57(33051) - 10.1.0.3(389)
1 1 0.0107
%, but I suspect that tethreal is *trying* to
interpert/decode everything on TCP port 389 as LDAP.
What it sees though is the SSL/TLS handshake/data and so it spews
meaningless LDAP protocol errors.
Dax Kelson
__
OpenSSL Project
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
to further debug/diagnosis it. I'm more
than happy to test out patches though.
Dax Kelson
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL
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).
I added a check for SSL_get_error, and I get
On Fri, 8 Feb 2002, Howard Chu wrote:
Try using strace to log all system calls. Until you know which calls have
failed, it's tough to isolate what's going on.
when using strace on sshd, I couldn't get it to fail. Not using strace, it
fails every time.
Dax
