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
ot; 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?
I really appreciate you taking the time to look at this.
I can't say 100%
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 (0
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
&g
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
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 SSL_ER
Feb 7 02:12:18 mooru sshd[19396]: TLS: can't connect. (other debug I added)
Feb 7 02:12:18 mooru sshd[19396]: pam_ldap: ldap_starttls_s: Connect error
At this point, I am at a loss how to further debug/diagnosis it. I'm more
than happy to test out patches though.
Dax Kelson
