On Tue, Feb 12, 2002 at 12:31:32AM -0500, William Waites wrote:
> On Mon, Feb 11, 2002 at 10:19:13PM -0600, Paul Dokas wrote:
> > 
> > Personally, I'd settle for the OpenBSD sol'n of just passing the bridged
> > traffic through IPFilter.  However, I think that a much better solution
> > would be something like the ZPC that Jason Thorpe was once working on:
> 
> Actually, the bridge code was ported from OpenBSD -- Jason Thorpe did
> 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.

Could someone please explain why the calls into IP Filter were removed
from the bridging code?  I've looked at the filtering bits in the OpenBSD
code, and agree that it's pretty damned ugly.  But, it's also extremely
useful and it's a pretty small change for the added feature of filtering
a bridge.


Lately, I've been experimenting with alternatives.  I've been combining
bridged (from pkgsrc), libnids and my own code in an effort toward
building a userspace filtering bridge.  And, except for TCP state tracking,
I've done a fair amount of the work.  However, after doing all of this
work, I've reached the conclusion that I'm just reinventing IP Filter but
in user space.  I think that it would be better to just add the IP Filter
calls back into the bridging code for several reasons:

  + it'll be faster in the kernel
  + IP Filter is far more robust and has few bugs than my code
  + IP Filter has all of the necessary bits to track TCP state correctly
  + people already know how IP Filter works and what to expect from it

I know that the code is ugly and I know that, conceptually, filtering IP
packets does not belong in the briding code.  But, it works for IP, it
doesn't add much new code to the kernel and for speed, it's in the kernel.


Can we just get the IP Filter calls added back into the bridging code?
Please?  Perhaps wrapped by:

  options  REALLYGROSSFILTERINGHACKYOUVEBEENWARNED

in the kernel config.


I fully expect that someone will at some point in the future put a fully
featured packet classifier into the kernel and filtering a bridge will be
done correctly and efficiently.  However, until then, I'd like to have
a temporary solution.  And, in my opinion, running packets through IP Filter
from the briding code is about the best and easiest way to do this.  I
also doubt that I'm the only one who could use this feature.

>                               I don't believe it would be very difficult
> to add it back in unless there's a particular reason not to.

Indeed, the diffs are not too big.  I guess that for now, I'll just bite
the bullet and add these diffs via CVS on my machine.


Paul
-- 
Paul Dokas                                            dokas@cs.umn.edu
======================================================================
Don Juan Matus:  "an enigma wrapped in mystery wrapped in a tortilla."