Date: Thu, 25 Oct 2001 19:21:43 -0700 (PDT) From: john_wilson100@excite.com To: Matthew Dillon <dillon@apollo.backplane.com> Cc: drais@wow.atlasta.net, freebsd-stable@FreeBSD.ORG Subject: Re: 4.4-STABLE machine unusable (was Re: Openssh) Message-ID: <1406043.1004062911549.JavaMail.imail@pugsly.excite.com>
next in thread | raw e-mail | index | archive | help
Thanks guys, that certainly clears things up for me!
I just have two questions:
1) if my Solaris box is similarly firewalled, why doesn't it exhibit the
same behaviour? I realise that their MTU discovery algorithm is probably
very different, but perhaps worth exploring or even adopting (now that
Solaris source is freely available)?
2) I want to have some proof and find out exactly which router or firewall
is causing this before I go medieval on them. Will I see MTU discovery in
a tcp dump?
Thanks again,
John
On Thu, 25 Oct 2001 18:40:37 -0700 (PDT), Matthew Dillon wrote:
TCP does what is known as MTU discovery to figure out the lowest MTU
in the connection path. TCP then sets the no-frag bit on its packets.
This can break down if you are running through a misconfigured firewall
or an intermediate router or machine does not respond with the correct
ICMP error when an oversized no-frag packet is received. If the
firewall blocks ICMP error #3 (destination unreachable) subcode 4,
your TCP connection will not properly detect the MTU.
Reducing the client machine's interface MTU is a work-around (it sets
a maximum MTU which is hopefully less then the maximum MTU of routers
in between you and the destination), but the best solution is to figure
out where the misconfigured router/machine is and fix it.
-Matt
On Thu, 25 Oct 2001 david raistrick wrote:
I've seen this before, or something that sounds identical. telnet did the
same thing, and anything over a size i dont remember via http did it as
well.
The workaround I found was to drop the MTU on the ethernet card (a generic
ne2k card at the time, no idea what it was plugged into.) down to 512 and
it was fine. Move it above 512 and the problems came back.
This was with 3.0 and 3.3 release...that machine was only recently pulled
out of service. sshd version 1.2.27 [i386-unknown-freebsd3.0], stock
telnet, and i'm not sure what apache.
(happened to /all/ available clients that i could find..)
If i only issued "short" output commands, 1/2 to 1 page (80x24) long, the
problem didnt seem to crop up. after that, it would hang.
I DID discover that it was still accepting my input....I could do a
"w" from another session, and see the "more" that was running on the other
tty. hit "q" on the hung session, and i'd drop back to the shell.
I could even logout.
anyway.
...david
---
david raistrick (deep in the south georgia woods)
drais@atlasta.net
_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1406043.1004062911549.JavaMail.imail>