Subject: Re: DLT/bpf questions
To: Iain Hibbert <email@example.com>
From: Greg Troxel <firstname.lastname@example.org>
Date: 10/04/2005 15:44:03
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
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
Greg Troxel <email@example.com>