On 06.08.2004 15:21 +0200, edp dot lists at acerbis dot it wrote:
> This could become a problem if you have a service behind the
> firewall ( like web server ) that generate big packets with df
> set, in order to improve internet performance (yes, a workaround is
TCP should not experience any problems in this scenario because
m0n0wall automatically clamps the MSS on all TCP SYN packets that
pass through the WAN interface when PPPoE is used. In any case, you
cannot rely on PMTUD only in today's Internet.
> to lower mtu on lan host or disabling df bit, but it is still an
> ugly workaround).
> Is that a problem of my particular configuration, a known one or a
> freebsd related one?
I investigated this issue, and found that it only happens if the
packet in question matched a traffic shaper rule. Explanation:
If a packet passed to ip_output() needs to go through dummynet,
ip_output() returns 0 and the packet is queued. But when dummynet
later calls ip_output() on its own behalf (because the packet is
ready to be sent), the return value is completely ignored (see
sys/netinet/ip_dummynet.c, line 430). There is no code to detect
EMSGSIZE, which ip_forward() handles by replying with an ICMP type 3
(destination unreachable) code 4 (fragmentation needed and DF set)
This really seems to be a bug in FreeBSD that probably can't be fixed
cleanly with only a handful lines of code, and I'm considering filing
a PR about it.
At the moment, the workaround is to either disable the traffic shaper
or to make sure that packets that could potentially trigger this
issue (and as stated above, because of the MSS clamping, this does
not affect TCP) do not pass through a dummynet pipe/queue (i.e. do
not match a traffic shaper rule).