Re: [Savannah-help-public] Problem with ssh access to git

[Trevor Daniels]

Sylvain, you wrote Saturday, February 27, 2010 3:15 PM

> This reminds me of MTU networking issues - as soon as there's a 
> big
> enough packet, the connection hangs.

This was the clue I needed.  SSH sets the DF bit in the
IP header to prevent packet fragmentation.  This is
deliberate to avoid a potential security exposure. So
if a packet is sent which is greater than the smallest
MTU in the route the packet is lost.  Normally the smallest
path-MTU is determined by Path MTU Discovery, but this
relies on ICMP-can't-fragment errors being transmitted
back to the two ends.  Many routers now filter all ICMP
packets, a stupidity which prevents Path MTU Discovery
working.  The result is the session hangs with the same
too-large packet being transmitted, getting discarded when
it needs to be fragmented and being requested again after
a timeout.

This fits exactly the symptoms I see: hangs occur only
when using an SSH tunnel, and only when large files are
being transmitted.

On to the the fix ...

> To precise what that means technically and give you a few 
> keywords, I
> usually need to add this to my router to work-around the problem:
>
>  iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o 
> ppp0 --clamp-mss-to-pmtu

I tried this, but it was ineffective.

> It could be that either the ms woe routing, or your ISP, changed
> something in the IP packet size recently, which triggers your 
> problem
> due to various NATing in your network route (Linux -> vmware -> 
> woe ->
> router -> isp -> inet).

I looked at my local router.  Its MTU was set at 1458.
This was the default; presumably it's the best value for
the PPPoA connection which my ISP provides.  I tried
reducing the MTU to 1400, thinking Path MTU Discovery
would then cause a smaller packet size to be used.  No
change.  I then tried increasing it to 1500, the ethernet
default, and this fixed the problem!

So what seems to have changed is the introduction of some
filtering of ICMP packets somewhere along the path, which
is now preventing Path MTU Discovery seeing my router's
smaller MTU value, and resulting in full-size ethernet
1500-byte packets being sent, which are then discarded by
the router upstream of mine as they cannot be fragmented
down to the required 1458.

For now I'll stay with my router's MTU set to 1500.  This
introduces only a small inefficiency, but when I get a bit
more time I'll try to determine where the block on ICMP
error packets is occurring.

Many thanks for all your help!

Trevor