Subject: DLT/bpf questions
To: None <email@example.com>
From: Iain Hibbert <firstname.lastname@example.org>
Date: 10/04/2005 20:04:46
I've been writing some protocol code and was looking at adding in a bpf
tap as it seemed quite simple but I'm a little confused about it and am
looking for a little clarification. Maybe somebody knows..
In 'struct ifnet', regarding if_dlt, the data link type - is this wholly
to do with bpf or does it need to be set for all interfaces? since there
is not a DLT defined for my protocols (AF_BLUETOOTH) should I just add
There is a problem, in that bluetooth headers are seemingly variable
length and thus allegedly unsupported - there would be four packet types
at the HCI interface where I wish to place the tap, with type indicated by
the leading byte and the relevant packet headers are then either 3, 4 or 5
bytes - should I maybe set the header length to 1 byte?
In fact, I've been reading the code you'll be glad to hear and I'm
thinking that the header length reported to bpf is in fact the 'data link
header', whatever that might be, not the actual packet header which I
think maybe bluetooth does not have in any case? (I dont seem to have
written any code to handle it in any case :)
So, assuming thats right and in fact there is no data link header, if I
call bpfattach() with hdrlen 0 and set if_dlt to DLT_NULL or maybe
DLT_RAWAF(AF_BLUETOOTH), it will surely pass the packet through, is that
going to work? I think that is what I want..
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? It does not
seem to make any difference to the packet capture code that I can see
(except maybe blocking the actual packet from the filter program?) and I
cant see a good reason to do it in my case, unless it is needed further
down the line? if so, where? (I can't find it...)