Re: Is ssh to Savannah failing?

[Trevor Daniels]

Carl Sorensen wrote Tuesday, February 16, 2010 8:09 PM

> On 2/16/10 10:46 AM, "Trevor Daniels" <address@hidden> 
> wrote:
>
> > ssh: connect to host 199.232.41.69 port 22: Bad file number
> > fatal: The remote end hung up unexpectedly
>
> I got this problem when I had a bad ssh key.

Well, with help from Sylvain Beucler at gnu I finally
tracked this problem down.

The "bad file number" error occurred in Vista, and
is misleading.  In ubuntu the session simply hung,
and it was here that I did the detective work.

In short, the real source of the problem is out of
my control, but a work-around was to change the MTU
setting in my domestic router from 1458 to 1500.

The long explanation, mainly for the record in case
anyone else encounters this, follows.  Press the delete
key now if you're not into internet procedures.  I'll
skip all the work needed to eliminate dead-ends and red
herrings, which actually took up most of the time.

--- the long explanation ---

First some background.  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 simply discarded as
fragmentation is not permitted.  Normally the smallest
MTU in the path is determined by Path MTU Discovery
during call set-up by sending test packets with DF set
and inspecting the returned ICMP packets containing
can't-fragment errors which result if a router in the
path has an MTU setting smaller than the packet.  But
this relies on ICMP packets being safely transmitted back
to the two ends and many routers now filter out all ICMP
packets, a stupidity which prevents Path MTU Discovery
working.  The result is the two ends see no errors and
assume the Ethernet MTU default of 1500 is OK, resulting
in packets being transmitted which are too large.  These
are simply discarded when they need to be fragmented,
resulting in either session hangs or a failure to open
a connection after a timeout, depending on whether the
error is first encountered during call set-up or later.

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 ...

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.  Joy!

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 the DF bit prevents their
being fragmented down to the 1458-byte size required by
my router.

For now I'll live with an MTU of 1500, as this is only a
slightly less efficient use of ATM frames, and I can
finally get back to LilyPonding.

Trevor