hunting for an MSS option to clamp. The previous code assumed that at least
one more byte of options (such as a TCPOPT_EOL) would follow the MSS
option; now, we allow the MSS option to end on the last byte of the
TCP header.
Packets have been observed "in the wild" with a TCP header length of
'6' (24 bytes.. 20 bytes fixed header, 4 bytes options) with a 4-byte
MSS option exactly filling the 4 bytes of options payload and no
following TCPOPT_EOL.
RFC793 is quite explicit that the EOL byte:
" .. need only be used if the end of the options would not
otherwise coincide with the end of the TCP header."
Configured by a new option "mssclamp" in NAT rules, like:
map pppoe0 192.168.1.0/24 -> 0/32 mssclamp 1452
This is based on work by Xiaodan Tang <xtang@qnx.com>.
There is no place in the source where this bit could ever be set (or I'm
to blind to find it).
This fixes PR 12671.
If someone thinks this is the wrong solution, please make sure to (a) reopen
the PR and (b) explain to me how the tested bits would ever get set. I'll
be glad to then look further for the real cause (i.e. the flags not getting
set in the case described in the PR).
rev 1.35 of ip_nat.c checks if packets are too short.
For ICMP packets, this packet length checking double counts
the length of an IP header contained in ICMP messages.
So, unless ICMP packets are long enough (such as echo-reply),
packets are mistakingly considered too short and are dropped.
silly differences between the NetBSD copy of the code and the
vendor branch, keeping only those which are necessary. Of those
differences that currently exist, several "portability to NetBSD"
issues, which will be fed back to the ipfilter author.
