The reason this affects v6 and not v4 is due to the difference in
in6_setmaxmtu() and in_setmaxmtu(), the v6 version only checks for
loopback whilst the v4 version checks for not loopback and also that the
interface is up. I think the v6 version should change to the same as the
v4.
At the same time, I wonder if the pflog interface type should have the
LOOPBACK flag set on it? There are currently no flags on it and given
that in6_setmaxmtu() / in_setmaxmtu() seem to base real vs virtual
network interface on the LOOPBACK flag and pflog seems to be a sort of
virtual interface type. If this interface were to be brought up then
IPv4 would similarly have an excessive MSS on it. Are there any
drawbacks to setting the LOOPBACK flag on an interface type that I might
be missing?
Of course the simple workaround of setting net.inet6.tcp6.mss_ifmtu=1
works around the issue, but I'm looking at the root cause.
Thanks,
Nick Reilly.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Zoltan
>I second adding LOOPBACK to log interfaces.
IFF_LOOPBACK has specific meanings in multicast and routing and
is used for some shortcuts. I don't think that any of this
is true for the pflog interface.
--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."
Thanks, that's the kind of thing I was worried about. Any thoughts on
how to mark the pflog interface as a virtual interface that shouldn't be
considered for max MTU calculations? Looks like the IFF_* flags field is
full currently although it is a short so could be expanded to a long and
add a new flag type, but that would be rather a large change to solve
this small issue.
Regards,
Nick.