Hi,

NetBSD doesn't appear to be handling the TCP MSS option properly.
According to RFC 1122, the MSS sent by a host is the maximum IP packet
size its willing to receive minus 40.  This correlates to the maximum
tcp payload when no tcp or ip options are present.  However, NetBSD
appears to use it as the maximum tcp payload even when options are
present.

I first noticed this trying to ftp to ftp.netbsd.org - what version of
NetBSD does it run? (www.netbsd.org exhibits the same behaviour)  If I
open an FTP connetion to ftp.netbsd.org with a TCP MSS of, say, 1360 (by
eg. setting my MTU to 1400), I get back packets with TCP payload up to
1360 bytes.  However, ftp.netbsd.org uses the TCP timestamp options which
add 12 bytes to the TCP header.  the result is that I get a 1412 byte IP
packet back, which would have had to be fragmented had my MTU really been
1400.

Although this is a fabricated example, I have a real problem from my
machine at home which is connected to the net with PPPoE (mtu 1492).
Infact, I can't ftp to ftp.netbsd.org from inside my lan as it appears
ipnat isn't handling the fragments properly (its strange because it
handels the fragments I get from www.netbsd.org properly, but I'll look
into that seperately).

I have verified this behaviour under NetBSD-current (1.5Y), but only when
pmtu discovery is enabled.

For some reason if pmtu discovery is disabled, NetBSD only sends tcp
segments up to 500 bytes (552 byte IP packets) through my pppoe interface,
even though (in this case) an MSS of 1360 was received and 1452 was sent.
Is this behaviour by design, or a bug?

I haven't had a chance to look into the source for either of theese
problems, but I hope to have time this weekend if someone doesn't beat me
to it.

Thanks,
	Rick