(please CC on replies, I'm not on netfilter-devel or netdev)
Version 0.0.4pre1 of the bridge-netfilter patch is available. There's a
bunch of loose ends to clean up, but in its currently form it's mostly done.
It consists of an extra file in net/bridge/ plus a number of miscellaneous
modifications to the rest of the tree, some of which controversial. I will
discuss the 'intrusive' modifications briefly.
1. Add a threshhold hook macro, NF_HOOK_THRESH, which only calls hooks
that have elem->priority >= specified_threshold. nf_hook_slow is extended
with an argument for passing this threshold. This is necessary for
stealing packets from a hook chain and reinjecting them later on, which
the bridge-netfilter stuff needs. At LK2001 there was a suggestion to
use QUEUE for this, but I can't see how this can be used cleanly, as only
one queue handler per protocol family can be registered, and this would
conflict with the existing use of QUEUE.
2. Add members ->physindev and ->physoutdev to struct sk_buff. This is
necessary for 'interface transparency'; the ability to filter on enslaved
devices in iptables rules transparently. For example, if eth0 is enslaved
to br0, and a packet comes in from eth0, destined for the local machine,
iptables -A INPUT -i eth0 -j DROP
would drop the packet if you have interface transparency. It's easy to
see that in this case, you need to keep at least one extra variable with
the sk_buff to make the mentioned rule work. In the case of a locally
originated packet, you also need at least one extra member. In the case
of an IP-forwarded packet with both source and destination interfaces
being bridge interfaces (sounds somewhat artificial, but there actually
are such setups), you need two.
3. Copy hardware header upon refragmentation. Without bridge-nf, in the
case of a locally originated or forwarded packet, refragmentation is done
in IP/POST_ROUTING (ip_refrag), while neighbour resolution is done after
IP/POST_ROUTING. bridge-nf needs to move the refragmentation to
BR/POST_ROUTING, which is after neighbour resolution, so we effectively
switch the order of the two. Refragmentation doesn't copy hardware
headers, so this causes us to send out packets with corrupted hardware
(1) is slightly messy because it adds yet another argument to a function
that already takes 6 arguments, but otherwise it's not really a big deal.
(2) touches on something that has been sparking holy wars for ages. If
you want interface transparency, you need these members. No further
(3) is ugly, with the alternatives being even more ugly.
The bridge-nf patch has lived outside the tree for a while, and some educated
guessing, based on the prevailing attitude I have experienced at LK2001, says
that (2) (and perhaps (3) as well) will prevent it from being accepted into
the tree at all. It's likely to end up in netfilter patch-o-matic. Currently
it is available at: