From:	 Lennert Buytenhek <buytenh@gnu.org>
To:	 netfilter-devel@lists.gnumonks.org, netdev@oss.sgi.com
Subject: [RFC] bridge-netfilter patch 0.0.4pre1 available
Date:	 Thu, 6 Dec 2001 15:43:34 -0500
Cc:	 bridge@math.leidenuniv.nl

(please CC on replies, I'm not on netfilter-devel or netdev)


Hi,

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
   headers.


(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
comment.

(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:

	http://bridge.sourceforge.net/devel/bridge-nf/


cheers,
Lennert