In some email I received from Jonathan Stone, sie wrote:
> 
> Did anything come of the discussions earlier this year about
> using bpf as a mechanism to identify and *drop* packets?

Yes, well, sort of.

I tried to implement it but at that time I had other things going on.

Main problem was bugs in the pcap library which generate buggy BPF
programs when you specify something like loopback as the interface
to use.  This was what stopped me, in the end (I had the code for
filtering in the kernel using BPF done, with support code to drop,
pass, etc).

Why as this a problem ?  I didn't really find the idea of filtering
IP packets at the interface level at all attractive and the BPF code
otherwise generated would have been incorrect.  There are ways around
this, but I've done some more reading on packet filtering, and BPF
_ISN'T_ as good as it can get.  PathFinder* (from '94 OSDI) was faster
than BPF, and my bet is primarily that they weren't using an interpreted
language.  If I can filter a packet on a complete rule in less time than
it takes to get half way through a BPF rule, which is better ?  There
are other "problems" with using BPF in this role too.

If you're looking for something, checkout
http://coombs.anu.edu.au/~avalon'/ip-filter.html

darren

* the aim of Pathfinder was develop a mechanism for routing ip packets
  at high speed (gigabit speeds) which could be used in hardware for most
  packets and software when forced to or when variation is required.
  In reflection, I found some of the choices I'd made for the above were
  present in this paper in their discussion of IP cells.  This paper can
  be gotten at: ftp://cs.arizona.edu/xkernel/Papers/pathfinder.ps