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 
level protocols.

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   ...
 	ifnet              if_bt
 	protocol            hci
 	protocol           l2cap
         protocol     rfcomm  sdp  bnep obex  ...
         protocol      ppp

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.

iain