Subject: Re: adding an 802.11 data link type
To: None <email@example.com>
From: David Young <firstname.lastname@example.org>
Date: 08/07/2002 13:36:26
I agree that there ought to be an bpf_mtap2 with an argument for the
header length. If people think that the flags belong, I will add them,
too. But please explain why an interface should pass the DLT to bpf_mtap2.
When there is a bpf_if per DLT, bpf_mtap2 will know the DLT by its bpf_if
argument, so passing it in is superfluous.
BTW, I advocate a bpf_if per DLT because everything a bpf_if stores for
an interface---list of listeners, DLT, header length, etc.---we need to
keep per DLT, anyway.
On Wed, Aug 07, 2002 at 10:48:32AM -0700, Matt Thomas wrote:
> At 10:34 AM 8/7/2002, Bill Studenmund wrote:
> >On Tue, 6 Aug 2002, Atsushi Onoe wrote:
> > > > > > 1) A driver supporting more than one DLT will call bpf with a new
> > > > > > procedure, bpfattach_multidlt, passing bpfattach_multidlt a mask
> > > > > > describing the DLTs the driver supports.
> > > > >
> > > > > Since the number of supported DLTs for a driver would be limited,
> > > > > multiple calls to bpfattach_dlt() may be accepted.
> > > > > This would help to implement streight forward implementation which
> > splits
> > > > > bpf_if for each DLT.
> > > >
> > > > But do we want multiple bpf_if's? My original idea was there would be one
> > > > bpf, just it could hand back different packet types.
> > >
> > > Hmm, I've found my previous implementation. I admit it is something like
> > > ad hoc, but it works well and it has complete compatibility.
> >That code is missing one of the key points:
> >+#if NBPFILTER > 0
> >+ if (ic->ic_rawbpf)
> >+ bpf_mtap(ic->ic_rawbpf, m0);
> I've been quiet on this for a while but no longer. :)
> Since BPF gives the driver an opaque hook into the interface, if_bpf, there's
> no need to change that part of the driver interface. What you really want
> are additional bpf calls,
> bpf_tap2(caddr_t if_bpf, caddr_t ptr, size_t len, int flags)
> bpf_mtap2(caddr_t if_bpf, struct mbuf *m0, int flags)
> We will define flags so the bottom 16 bits are reserved for passing an
> optional DLT type. Then if you need special processing, you can just do
> bpf_map2(ifp->if_bpf, m0, DLT_IEEE80211B | DLF_RX);
> (Since we are extending BPF, we might as well add support for passing in
> the direction of the packet).
> Now, all the big changes are in BPF. This can uses for other interfaces
> which can change packet modes (for instance, between CHDLC and PPP).
> Matt Thomas Internet: email@example.com
> 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
> Cupertino, CA Disclaimer: I avow all knowledge of this message
David Young OJC Technologies
firstname.lastname@example.org Engineering from the Right Brain
Urbana, IL * (217) 278-3933