Re: RFC: Disable defered bridge hooks by default

[Philip Craig <philipc@snapgear.com>]

Patrick McHardy wrote:
> I'm a lazy reader, so I didn't follow this entirely. But:
> 
> "-i <bridge> -o <bridge> "
> 
> implies you're using this for purely bridged traffic. The feature
> we're going to remove only affects locally generated traffic exiting
> on a bridge device, in that case iptables _can't_ know the output
> port.

It also affects forwarded packets that are routed out the bridge device?
ie anything that is routed out a bridge device, because iptables sees
the packet before bridging does its stuff.  Purely bridged packets are
fine though, because they don't actually leave the bridge device, the
bridging code just calls the netfilter hooks at the appropriate time.

Would it be possible to call the bridging code from the iptables
forward/output hooks, store the result somewhere, and then when the
packet is passed to the bridge device, just use the stored result?
So fix the problem by calling bridging early, instead of deferring
iptables?  I'm not sure if this could handle packets that need to
be sent out multiple ports.

And possibly related, could this be done for arp lookups too, so
that output mac matching is possible?

> But you can do your iptables matching, mark matching packets
> and filter on the mark within ebtables.

I haven't thought about this too much, but for a high-level tool,
the rules can theoretically be too complicated for this to be feasible.
The worst case will be to perform all the possible matches that are
supported by iptables but not ebtables, and encode the result of all
of these into the mark.  And even if this can be optimized, I can
imagine the code to do it being quite complex.