Subject: Re: adding an 802.11 data link type
To: None <tech-net@netbsd.org>
From: David Young <dyoung@ojctech.com>
List: tech-net
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.

Dave

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);
> >+#endif
> 
> 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:   matt@3am-software.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
dyoung@onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933