> > Hum, well I don't have other ideas, sorry.
> > This works fine from home, where I also use ftp though ipnat with a adsl
> > (pppoe) connection ...
>
> What a minute ... I had to turn off 2 sysctl to have it working.
> One was net.inet.tcp.rfc1323, I don't remember the second one.
> Maybe net.inet.tcp.init_win, or net.inet.tcp.mss_ifmtu

Right...

Turning off timestamps (by disabling all rfc1323 extentions, or just
disabling timestamps themself) will mean the data packets won't
contain TCP options.  If there are no options in the TCP packets, NetBSD
will adhere to the MSS it was given (the bug is that NetBSD doesn't take
the length of the options into account).

Telling your gateway to set its MSS based on the MTU of the specific
outgoing interface (mss_ifmtu=1), will mean it will use an MSS that should
(assuming the other side is behaving, and there isn't some smaller MTU
link in the middle) prevent fragmentation.  You probably want to be using
a properly low MSS anyway because of all the buggy PMTUD blackhole sites
(i.e. try getting to www.bmo.com).

Most PPPoE software (rp-pppoe, but not -current pppoe interface) suport
TCP MSS clamping where the MSS in all TCP SYN packets is modified.  Using
this feature will have the same effect (depending on what value to clamp
to - 1462 is ideal) as setting mss_ifmtu=1 but will also affect packets
that originated from other hosts.  You could even clamp the MSS 12 bytes
lower to prevent the buggy ftp/www.netbsd.org packets (without having to
disable timestamps - timestamps add 12 bytes to each TCP header).

So in the one machine scenario, yes setting net.inet.tcp.rfc1323=0 and
net.inet.tcp.mss_ifmtu=1 should prevent fragmentation in most situation
and work around the problem.  However this doesn't help the other
situation in which fragmentation can arise, specifically:
- using something other than TCP which might use large packets
(WindowsMedia streaming over UDP was a problem for me)
- hosts behind your gateway who know nothing about the lower MTU at the
gateway.

Rick