Subject: Re: DLT/bpf questions
To: Greg Troxel <email@example.com>
From: Iain Hibbert <firstname.lastname@example.org>
Date: 10/05/2005 07:54:44
On Tue, 4 Oct 2005, Greg Troxel wrote:
> So the bluetooth frame arrives and has a type byte first, and then
> addresses beyond that? In that case, it feels to me like the header
> length is 0 and it's all data. Is this the complete on-the-air frame?
> Or is this after some parsing?
This is what comes out of the device (controller). The computer (host) is
completely insulated from on-the-air. This HCI (host-controller-interface)
level contains four packet types, command (h->c) and event (c->h) packets and
acl (data) & sco (audio) which are connection based and encapsulate higher
So yes, I think the header length could be 0, though it could also be 1 since
the type byte is common to all packets.
This is to be a bluetooth protocol stack, in netbt/
The current bluetooth code in NetBSD is only a character device interface to
the hardware. All I have done really, is turn it into a sockets based interface
to this so other protocols can layer on top.
it goes something like:
device ubt bt3c ...
protocol rfcomm sdp bnep obex ...
I have bt3c, if_bt and hci working (there is a [probably more useful] usb
driver for the character device but its waiting until I get a bluetooth
dongle). I'm wanting to insert bpf taps at if_bt level so I can watch what goes
on once I start upstream.
My net access is rather limited until mid month (9600bps @ 15c/min) but once I
get to the wireless zone again I will upgrade my system to -current (from 2.0)
and submit a patch.