Hear is my thinking about the implementation, so far.

I will add an optional list of alternate DLTs to interfaces:

  /* ifde_dlt is an eligible data link type (DLT). ifde_bpf is the packet
   * filter structure for that DLT.
   */
  struct ifdltlistelt {
          u_int ifde_dlt;         /* data link type */
          caddr_t ifde_bpf;       /* per-DLT packet filter structure */
  };

  /* Variable-length structure listing an eligible data link types (DLTs)
   * for an interface.
   */
  struct ifdltlist {
          u_int ifdl_count;                   /* length of ifdl_list */
          struct ifdltlistelt ifdl_list[1];   /* records for eligible DLTs */
  };

  struct ifnet {
          /* ... */
          struct ifdltlist *if_dltlist;   /* alternate data link types */
          /* ... */
  };

For an interface's second and subsequent calls to bpfattach, if they
use different DLTs, I will add second and additional bpf_if's to the
bpf interface list.

For an interface's second and subsequent bpf_if's, bif_driverp points to
the bpf_if pointer in the alternate data link list instead of ifp->if_bpf.

To support variable length 802.11 headers, I will add a routine
bpf_mtap1(arg, m, hdrlen).  I will re-define bpf_mtap(arg, m) as
bpf_mtap1(arg, m, ((struct bpf_if *)arg)->bif_hdrlen).

I will add to bpf both the ioctl's BIOCSDLT (u_int) and BIOCGDLTLIST
(struct bpf_dltlist):

  #define BPF_DLTLISTSIZ 10
  struct bpf_dltlist {
          size_t	bdl_len;
          u_int		bdl_dlts[BPF_DLTLISTSIZ];
  };

BIOCSDLT is self-explanatory. BIOCGDLTLIST will store up to BPF_DLTLISTSIZ
dlts in bdl_dlts and set bdl_len to the number it stores, unless the
number of DLTs exceed BPF_DLTLISTSIZ. In that case, it writes to bdl_len
the total number of DLTs for the interface.

I will add the 802.11 DLT alternate and the Prism alternate to wi and test.

All this involves simple modifications to wi, bpf, and ifnet.

Will libpcap and tcpdump need changes to handle variable-length 802.11
headers, or do they already do that?

Dave

On Mon, Aug 05, 2002 at 02:51:32PM -0700, Bill Studenmund wrote:
> On Mon, 5 Aug 2002, Atsushi Onoe wrote:
> 
> > > I would like to add an 802.11 DLT to NetBSD so that I can observe 802.11
> > > mgmt/ctl frames through bpf.
> >
> > Sorry for lazy activities on this topic...
> >
> > > In the discussion on the 802.11 DLT in May, it appears that a rough consensus
> > > was reached, namely that
> > >
> > >  0) DLTs DLT_802_11, DLT_PRISM_802_11, DLT_AIRONET_802_11 are desirable
> > >     in addition to DLT_EN10MB.
> >
> > I think it would be better if we define DLT_DRVSPEC for all driver specific
> > raw format, since I don't want to implement DLT_AIRONET_ for 'wi' driver.
> 
> I think all the different specific types would be better. Note though that
> the wi driver wouldn't need to do DLT_AIRONET_.
> 
> > >  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.
> 
> > >  2) 802.11 interfaces will default to handing up 802.3 frames to bpf,
> > >     so that dhclient, tcpdump, etc. do not break.
> >
> > >  3) Two new ioctl's list/choose the DLT used by bpf:
> > >
> > >       BIOCGDLTS -- returns a bit vector. "Lit" bits indicate supported DLTs.
> > >                    For example, on an 802.11 interface, the DLT_EN10MB'th
> > >                    bit and the DLT_802_11'th bit will be set.
> >
> > It seems that the range of the value for DLT is not defined. BIOCGDLT
> > just uses u_int to pass it.  So returning array of supported DLTs would
> > be better.
> 
> Right.
> 
> Take care,
> 
> Bill

-- 
David Young             OJC Technologies
dyoung@onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933