On Thu, 6 Dec 2001, Richard Rauch wrote:

> > Not sure if this is the only thing causing a problem for you, but it
> > appears your experiencing a problem I discovered a couple weeks ago.
>  [...]
>
> It's a good explanation for why I only have trouble with ftp.NetBSD.org.
> However, your suggested fix doesn't work for me with ipnat in NetBSD
> 1.5.2.  It also doesn't explain why http://www.NetBSD.org hangs the same
> way.

That is true, there is more going on than just the problem I described.

> 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
www.ipfilter.org) should fix the problem of fragments not getting
forwarded properly (if I recall correctly anyway - I think that is why I
installed a new ipfilter on my old 1.5-release gateway machine).  That is
the real problem, and is the best solution.

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.

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
MSS to atleast 1452.  If you're using the rp-pppoe package, there is a
CLAMPMSS option you can set.  That will cause all TCP packets going
through your PPPoE connection to have their MSS lowered to 1452.  Except
in the case of broken NetBSD servers, this will prevent fragmentation by
keeping TCP packets bounded to 1492 bytes (the MTU of your PPPoE
interface).  I don't think mouse-pppoe supports MSS clamping, and neither
does the new pppoe software in -current.

To lower the MSS when your pppoe software doesn't support MSS clamping,
you can set net.inet.tcp.mss_ifmtu=1 on your gateway - that will fix tcp
sessions originating from there.  And either artificially lower the MTU of
your internal network to 1492, or add a "-mtu 1492" option on your default
route on your client machines.  This will cause them to also use a TCP MSS
of 1452.

Now, to work around the problem with broken NetBSD servers, you can either
lower your MSS by another 12 bytes (as NetBSD will send 12 extra data
bytes when timestamps are enabled), or you can disable TCP timestamps
(net.inet.tcp.timestamps).

Does this make any sense?  I know its confusing, there are a lot of
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 :)

Rick