Subject: Re: Patch for timiting TCP MSS (i.e. for new PPPoE)
To: None <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 12/04/2001 16:57:31
On Mon, Dec 03, 2001 at 10:01:48AM -0600, Hal Snyder wrote:
> Martin Husemann <firstname.lastname@example.org> writes:
> > Which still means you have to do it for each and every machine
> > behind a pppoe router. It's hard to cope from our understanding of
> > standards conformance, but we *realy* need a MSS clamping option for
> > routers!
> I'll second that. Setting MTU on routes isn't enough, in the case
> where you have NetBSD on an intermediate router. It will help to have
> a way to clamp (selectively) the MSS hint from a host on the inside as
> it passes through the router out a certain interface or out a certain
Actually, this problem impacts us so severely for two reasons:
1) We don't always use Path MTU in the default configuration. So, we use
an MTU of 1500 for "local" hosts -- and a NAT can make hosts seem "local"
that are actually not. If we always used Path MTU, even for "local" hosts,
a whole class of network configurations would stop giving NetBSD hosts
such a hard time.
2) Our NAT code appears to corrupt locally-generated needs-frag ICMP
messages, so a NetBSD router separating, say, an MTU-1400 PPPOE link
and an MTU-1500 Ethernet will create a Path MTU blackhole. I have an
open PR on this, but I last time I looked I couldn't figure out how
checksum regeneration for locally-generated ICMP messages was *supposed*
to work, so I couldn't fix it.
Bug #2 above is really serious and is probably responsible for many users'
complaints about PPPOE and Path MTU. With it fixed, we "shouldn't need a
terrible hack like MSS clamping; with it there, we probably do.