Re: RFC: Disable defered bridge hooks by default

[Amin Azez <azez@ufomechanic.net>]

* Patrick McHardy wrote, On 13/07/06 08:46:

>> 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.
> 
> No, it couldn't. Its questionable behaviour to do this anyway, think
> about something you REJECT without looking at the output port - you
> will reject once for each output port. The entire idea of using
> iptables from the bridge code seems flawed to me. Conntrack might
> also get very confused under certain cicurstances.
> 
>> And possibly related, could this be done for arp lookups too, so
>> that output mac matching is possible?
> 
> Theoretically yes, but I'm trying to get rid of a problem here,
> not introduce new ones :)

The difficulty I am now trying to solve is that of SNAT-ing bridged
traffic depending on the output port.

Bridging is really layer2 routing and so it makes a lot of sense to
handle it like this.

I'm currently looking at adding a bridge look-ahead target (similar to
Philips suggestion to see where a packet was likely to be bridged so I
can use that. It probably wants combining with physdev so that physdev
can use whichever strategy is suited whether the packet is routed or to
be bridged.

Sam