the little ssh that (sometimes) couldn't

Tue Oct 30 00:44:01 UTC 2012

:
:corruption!
:
:
:http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html

I ran into a similar issue with a customer just a few days ago!  The
customer's theory was that there was something badly wrong with their
dorky gateway/switch (which we sold and support <sigh>).  ssh was
timing out, with a SSH2_MSG_KEX_DH_GEX_GROUP hang/failure during the
ssh protocol exchange.  Based on that, some wireshark captures, and
and stray Google droppings, I advised them to ratchet down the MTU to
make things work.  Through bisectional MTU settings and pinging, we
arrived at an MTU of 850.  And I initially started cursing at the
switch (because that helps move packets, really :) ).

Turns out -- the ssh server in question was running RHEL 5.x Linux,
and that was the key.  Even though "ip route show cache" looked sane,
"ip route flush cache" (which I had them run, just on a lark) made 
the problem go away.  So it probably wasn't my switch (unless it had
done something untoward in the distant past that induced some weird
Linux stack bug).

I'm mostly posting this because I was wondering if anyone else had
run into an MTU of 850 before.  Is that a "magic number" that rings
any bells (or perhaps has seen the Linux route cache behavior I did).

-Mike

-- 
 Michael J. O'Connor                                          mjo at dojo.mi.org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"It is now the age of now."                                -Non Campus Mentis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20121029/c094131e/attachment.sig>