The DLT header is about the fixed part of the 'link level' header.
AF_NULL means that the first 4 bytes are the AF of the protocol,
followed by the data (e.g. INET, INET6).  So for bluetooth this could
work if you have AF_BLUETOOTH, followed by the bluetooth bits.

I'd look at tcpdump.org and perhaps linux to see if there is a
DLT_BLUETOOTH defined, to avoid gratuitous incompatibility.  Perhaps
also ask on the libpcap list there.

I'd avoid DLT_RAWAF() since that seems to be NetBSD private.

As for the header length: if you use DLT_NULL it's 4, but if you
define DLT_BLUETOOTH the question is for every bluetooth 'packet',
what are the fixed address header fields.  Those belong in the header,
and variable headers do not.  For Ethernet it's 14.

  I notice some other interface types dont seem to have a 'data link
  header' (as I'm calling it), and fabricate something with the AF to
  tack on the head of the packet (with bpf_mtap2 now). Why do they do
  this? 

PPP does this; it's a way to export the logical packets being conveyed
in a portable way to bpf users, rather than sending PPP frames.
Ideally you'd support both types (DLT_BLUETOOTH and DLT_NULL), so
people can see payloads with af types, or also the actual bluetooth
frames.

-- 
        Greg Troxel <gdt@ir.bbn.com>