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
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
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
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.48884610.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
Hi there,
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
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
