On Wed, Mar 06, 2002 at 08:57:59PM -0600, Paul Dokas wrote:

 > > most of the work. The BPF code was apparently taken out at that time,
 > > although I'm not certain why.
 > 
 > I've seen this point mentioned more than once.  In fact, I've also seen
 > several other people ask about filtering a bridge and wonder why that
 > was ripped out when ported.

It was ripped out because, quite frankly, it was too damn ugly and
totally the wrong approach.

Adjusting the packet, calling IP Filter, and then re-adjusting it to
bridge has a couple of problems:

	(1) Only allows you to filter IP.

	(2) System uses the same filter rules for bridge forwarding
	    as for IP forwarding or for local packet delivery.

At the time I orginally did the work, there were a couple more reasons
that I came up with, but I don't remember them right now.

My solution to this was to implement a totally new filtering system,
which had as fundamental design principles:

	* Multiple filtering points, each with their own rulesets.

	* The ability to handle more than just IPv4/IPv6.

The filtering project eventually grew in scope to be two parts:

	(1) A general-purpose packet classification engine.

	(2) A packet filtering packge based on it.

...the goal was also to make ALTQ use the same classification engine,
so that hacks like altq_etherclassify() could die (and so that you
could traffic-shape more than just IPv4/IPv6).

Unfortunately, the company I was doing the work at pretty much no
longer exists, so the project died.  However, before that happened,
I had the prototype working pretty well.  The test system provided
bridging+filtering of several VLANs, IP forwarding+filtering for
another set of VLANs, and filtering for local packet delivery, all
using different rulesets.  You could also filter non-IP stuff on
specific interfaces, e.g. "no, I don't want to receive any Appletalk
packets on fxp0".

As the core of my classification engine, I used BPF.  There were a couple
of reasons for this:

	(1) BPF is already in the kernel, and is flexible enough to do
	    everything a classifier needs to do.

	(2) There was already a basic ruleset-to-BPF compiler (libpcap).

	(3) BPF's instruction set is simple and well-structured for doing
	    runtime BPF-to-native code synthesis.  (I initially experimented
	    with this idea by writing a simple BPF-to-C translator, and
	    compiling the resulting C code.  The resulting rules ran extremely
	    fast.  Obviously, through, you want to do the BPF-to-native
	    translation in the kernel after allowing the kernel to verify
	    the BPF program for safety.)

If someone would like to pick up the ball on this project, I would be
more than happy to provide a brain dump, my old notes, and possibly some
old code.

(Paul?  Interested? :-)

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>