Stalls and closes

[Darren Tucker]

On Sun, Jan 08, 2006 at 04:46:49PM -0500, Tuc at T-B-O-H wrote:
> 	Interesting... I didn't mention that the transport is... Not FLAKEY,
> but SLOW. (Satellite on the remote end). How did you come to that 
> determination? (Just for the future so I can see it in debug others might
> send me). I don't have much packet loss :
> 
> -bash-2.05b$ ping -c 10 10.2.0.2
> PING 10.2.0.2 (10.2.0.2): 56 data bytes
> 64 bytes from 10.2.0.2: icmp_seq=0 ttl=64 time=837.061 ms

Try this again with a packet size equivalent to the path MTU.   I think
you'll need to use a ping packetsize of MTU - 28 bytes (but I might be
wrong, use tcpdump to watch the outgoing packets to get it right).

The thing that would really tell is if you could watch the SendQ sizes
in netstat on the server but from the sound of it that might not be
possible.  It's worth checking on the client side (look for a non-zero
and increasing queue size).

> 	The client is old, admitted, FreeBSD 4.10, but the server was
> just installed, FreeBSD 5.4! 

Don't FreeBSD still have their own mods to sshd?

> 	I forgot to mention that it stalls after :
> debug1: next auth method to try is keyboard-interactive
> 
> 	also.....
> 
> 	I was hoping for a way to fix it, its a 9 hour drive to the beachhouse
> that that server is at... 

Try reducing the MTU on the client's network interface, or similarly
limiting the TCP max segment size (ieg max-mss scrub option in pf, or
clampmss on Linux).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.