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