David Miller <davem@xxxxxxxxxxxxx> wrote:
> From: Florian Westphal <fw@xxxxxxxxx>
> Date: Tue, 17 Mar 2015 11:11:52 +0100
>
> > And doing route lookups will break things for some people, we have zero
> > guarantee that a bridge has the needed routing information,
> > its valid to not even configure a default gateway on a bridge.
>
> Then without a proper route you absolutely cannot choose an
> appropriate MTU from which to perform fragmentation.
Just to clarify, this ip_fragment call is done only for frames that
are forwarded by the bridge, i.e. not routed.
All interfaces have the same MTU.
So why would we need to chose an MTU different than the device
mtu, or larger than the largest reassembled packet?
Ideally, the bridge would re-create the original fragments it received
on 1:1 basis to make it fully transparent, and to make the bridge behave
as if it would not do the defrag layering violations in the first place.
> Just accept that basic fact.
For a router I'd agree, but, then again, we're a bridge. Normally we
would not fragment at all. The bridge defragmentation should not be
observable by external entity. No increase, no decrease of mtu, 1:1
fragment passthrough illusion.
I can leave ip_fragment alone and, when skb->nf_bridge goes away,
just replace
#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
if (skb->nf_bridge)
mtu -= nf_bridge_mtu_reduction(skb);
#endif
and
ll_rs = LL_RESERVED_SPACE_EXTRA(rt->dst.dev, nf_bridge_pad(skb));
With a functionally equivalent "solution".
But I'd really prefer to move these kludges out of the ip stack for good.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
