On Thu, 6 Dec 2001, Richard Rauch wrote:

> > > You mention that -current has a more recent version of ipf/ipnat.  Would
> > > updating my own system be likely to help?  I was going to put -current on
> > > my gateway anyway, and try letting it track -current.  (If the gateway
> > > dies a horrible death, I can always reinstall it---and I have backup
> > > access via my office should it be down for a protracted period; (^&)
> > >
> > > If there's some hope that I'd benefit from updating my gateway machine,
> > > then I'll table my ftp/www concerns for now...
> >
> > Yes, updating your ipfilter to atlest 3.4.16 by either upgrading to
> > -current, or just upgrading ipfilter manually (see the FAQ at
>
> I dropped in a -current kernel (snapshot from Dec. 1).  It seemed to have
> trouble with my old LinkSys (err, DLink? I forget which) ethernet card
> with the ``Lite-On'' Tulip clone chipset.  I'm not entirely sure, and in
> the blur of tweaks & twiddles, I don't remember enough details to say what
> I saw.  (I'll definitely get back to it; I'd like to run -current on the
> gateway, and resolving that ethernet problem will be an essential
> road-block.  (^&)

Hmm.. Well thats a seperate issue, we (most likely someone moew
knowlegable than me) can help you deal with it later.  I upgraded my
gateway to -current just to get the in-kernel pppoe support.  Its supposed
to be much more efficient than a userland solution like mouse-pppoe or
rp-pppoe.

> > However, as an interim solution you can avoid getting fragments from
> > ftp/www.netbsd.org by artificially lowering your MSS and/or by working
> > around the bug w.r.t. TCP options.
>
> Can you define MSS for me?

Sorry, sure.  TCP MSS is "maximum segment size".  It's an option that can
be put in the first packets of a TCP sesstion (the "SYN" packets) to
specify (roughly) the maximum about of data that can be put into a single
TCP packet.  Since both the TCP and IP headers are variable length (40
bytes plus any options), the MSS isn't quite "the maximum abount of data"
but is actually "the maximum IP datagram minus 40".  So when I ftp to
ftp.netbsd.org and my machine sends an MSS of 1452, I'm telling
ftp.netbsd.org to never send me an IP datagram bigger than 1492 bytes.
However, ftp.netbsd.org is broken and doesn't take the 12 bytes for the
TCP timestamp option into account and will actually send me packets up to
12 bytes longer.

> > What PPPoE software are you using?  Due to broken networks (PMTUD
> > blackhole problem - see my recent thread on tech-net about a patch for
> > limiting the TCP MSS), I suggest you make sure you are "clamping" your TCP
>
> I remember seeing a thred about TCP MSS and PPPoE.  (I'm using
> mouse-pppoe; I picked it somewhat at random.  It mostly works as I'd
> expect, except that I have to manually set the default route, even though
> I've put defaultroute in the /etc/ppp/options file (other options in there
> are picked up and processed correctly).)
>
> Unfortunately, mouse-pppoe has essentially no documentation with it.  (^&
>

I'd suggest you use the rp-pppoe package.  It's very popular (mostly used
on Linux) and has a few extra nicities, including TCP MSS clamping.
However, if you're planning on upgrading to -current and using its
in-kernel pppoe eventually, then you might be best off sticking with
mouse-pppoe for now as you'll have to work around the MSS problems later
anyway...

> > problems all interacting here...  Its unfortunant that, since most of the
> > world is connected to the net over a 1500 mtu link, people with a lower
> > MTU discover (and have to deal with) the bugs :)
>
> I've never had a problem before---but then, I didn't use NAT before.  (^&

Even without NAT, try going to a broken site like www.bmo.com without
doing MSS clamping or setting tcp.mss_ifmtu to 1, it'll just hang...

Anyway, if you just do a "route change default -mtu 1480" from one of your
clients behind the gateway (assuming its a NetBSD machine), TCP from that
machine should work fine.  It's not an ideal situation (the lower the MTU
the more overhead), but its a simple temporary work-around.

Rick