I have seen this problem on my server, a slackware linux box running
ssh-1.2.27. The client is a Windows 95 machine with the DUN1.3 update or a
Windows 98 machine. It appears to be a bug in the Microsoft TCP stack. The
linux box was using the TCP SACK or timestamp options. The linux box would
send a TCP ACK packet with one of the options and no data. The Windows box
would return an ACK packet with no data, but the packet had extra data at
the end which appeared to be left over from the linux ACK packet. It
appears the Windows box was using the same data buffer to return the ACK
packet and sent extra bytes that confused the linux box.
I fixed this problem by disabling the tcp_sack and tcp_timestamps on the
linux box. I added these line to my rc.local file to disable these options
at startup -
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
Good luck
Jeff Foster
[EMAIL PROTECTED]
-----Original Message-----
From: Stephen Bolinger [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 18, 2000 6:37 PM
To: [EMAIL PROTECTED]
Subject: SSH 2 Connection Error
Hello,
I have setup SSHD-2.0.13 on many Solaris machines, but I'm running into a
problem getting it to work on a RedHat 6.1 machine. Here's the error I get:
Jan 18 17:39:51 localhost sshd2[7785]: Starting daemon in inetd mode.
Jan 18 17:39:51 localhost sshd2[7785]: connection from "10.10.110.222"
Jan 18 17:39:51 localhost sshd2[7785]: Daemon is running.
Jan 18 17:39:52 localhost sshd2[7785]: Remote host disconnected: Protocol
error: packet too long: 1684365945.
Jan 18 17:39:52 localhost sshd2[7785]: Protocol error: 'Protocol error:
packet too long: 1684365945.'
Any ideas?
Stephen Bolinger
------------------------------------
Paramount Digital Entertainment
323.956.3226
