On Sun, 16 Jun 2002, Jo Geraerts wrote:
> 10:44:25.286209 217.136.250.136.33097 > 213.119.61.223.2223: . ack 311 win
> 6432 <nop,nop,timestamp 352628 67008766,nop,nop,sack sack 1 {299:311} > (DF)
> -------------------------------------------------------------------------------------------------------------------------------------------------------
The last packet that the clients sends acks 311 and at the same time
sacks 299:311 (although this range is included in the ack 311.
I believe this is called DSACK and is some experimental TCP feature.
Given that this is the last packet that gets through, it is suspiceous.
Try to switch it off (client side):
echo "0" >/proc/sys/net/ipv4/tcp_dsack
While you are at it, try to switch off the rest of the advanced tcp
features: tcp_ecn, tcp_sack, tcp_timestamps
The ssh debug output seems to indicate that the server closed the
connection, but there are no reset or fin packets in the trace. This is
strange, too.
You could try to rule out the network problems in the following way: Use
the working ssh user id to set up a ssh tunnel:
client> ssh [EMAIL PROTECTED] -L 12345:localhost:22
While this is running try to connect via the ssh tunnel:
client> ssh [EMAIL PROTECTED]:12345
Walter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
