netdev
[Top] [All Lists]

Re: [RFC] bridge-netfilter patch 0.0.4pre1 available

To: Lennert Buytenhek <buytenh@xxxxxxx>
Subject: Re: [RFC] bridge-netfilter patch 0.0.4pre1 available
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Thu, 06 Dec 2001 14:21:25 -0700
Cc: netfilter-devel@xxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, bridge@xxxxxxxxxxxxxxxxxx
Organization: Candela Technologies
References: <20011206154334.B3632@xxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2


Lennert Buytenhek wrote:

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


Does this scheme still work if you go:  eth0 -> vlan5 -> br0
(Does vlan5 or eth0 count as the physindev?)

Ben


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear



<Prev in Thread] Current Thread [Next in Thread>