Hi,
    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 
one?

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...)

regards,
iain