Subject: Re: packet filtering for an interface.
To: Darren Reed <darrenr@vitruvius.arbld.unimelb.edu.au>
From: Matt Thomas <matt@lkg.dec.com>
List: tech-kern
Date: 07/09/1995 13:04:08
> 
> I'm close to completing packet filtering, per interface, using BPF (i.e.
> libpcap), for NetBSD, at the interface level.  I don't believe that it
> will work successfully for pure IP packets (no link level header), but
> would welcome being corrected on this :)
> 
> All that is left to do is find the correct place to filter the packets
> (and test :).
> 
> I notice that for BPF, each driver does its own call to bpf_mtap().
> Are there any plans to move this (and reorganise some drivers) ?
> Is there a reason why bpf_mtap() isn't in if_ethersubr.c, for example ?

Some drivers also call bpf_tap.  Note that the tap routines are called
on both reception and transmission of packets.

A very good reason not to move the tap routine into if_ethersubr.c is
overhead.  When using packet filter in promiscuous mode, you don't want
have to give every packet to ether_input especially when it is going
to drop it.  Another reason is that bpf may only copy a portion of the
header so it's wasteful to copy the entire packet into an mbuf when only
the first 80 bytes will be looked at.

> Also, is there any point in trying to make this part of the code more
> device independant ?  To add the filtering in, I'd *really* prefer not
> to patch lots and lots of device drivers...

That's understandable.  Instead, why not modify bpf so you can dynamically
add private filters for processing?  

Matt Thomas               Internet:   matt@lkg.dec.com
3am Software Foundry      WWW URL:    <currently homeless>
Westford, MA              Disclaimer: Digital disavows all knowledge
                                      of this message