Hi,
   I've been working on Bluetooth protocol family for a little while now
and what I have is approaching usefulness, since I can open L2CAP sockets
and connect to a remote device and send/receive data now. There is still
some way to go, but would appreciate any comments as to architecture or,
well, anything - I'm sure there are some things I do wrong, or not the
NetBSD way, or whatever.  I put a page up at:

	homepages.rya-online.net/plunky/netbt.html

which has a patch file to apply to -current source plus a tarfile of some
tools/test programs that I use to make things work (mostly what is
necessary is btconfig and btd - the other bits I modify and recompile when
I want to check something but you can see at least how it works)

the current bluetooth code (in dev/bluetooth) is not used at all.

Everything I have done in kernel is in netbt/ (apart from pcmcia/bt3c.c
and usb/ubt.c) though some of it might want to move elsewhere (not sure,
really - can wait until later)

device drivers available are 3Com PC Card (works well) and generic USB
(apart from the fact that isochronous data not written, a couple of issues
- uhci locks up on system shutdown and usb device does not disable/enable
properly sometimes - I didnt really investigate that yet as I use my USB
port for a mouse most of the time :)

the device interface (from below) is in hci_unit.c. Initially I used an
ifnet interface but it wasnt turning out great, and this way sits better I
think.

incoming HCI packets are dealt with in hci_event.c and hci_link.c and is
driven entirely from a soft interrupt.

the l2cap API (from above) is l2cap_upper.c

hci RAW socket is hci_socket.c

l2cap SEQPACKET socket is l2cap_socket.c as an example of how to access
the l2cap API - hopefully it will be ok for other protocols to sit on
(rfcomm is my goal) without too many changes.

btconfig is basic but works and fairly easy to extend

	btconfig bt3c0 name "My Computer" pscan -iscan
		<set device name, set pscan, unset iscan>

	btconfig -s
		<print stats for all devices>

btd (stupid name) does nothing except answer the phone at the moment, but
should handle link keys and pin codes - not sure about interactive pin
code requests, will have to investigate how the other outfits manage it.

I gave up trying to keep separate include files so all defs are lumped
messily in btvar.h at the moment, may split it up again later though
l2cap/hci are fairly entwined so maybe not.

hci.h and l2cap.h originated from FreeBSD though I have made a few changes
- they prepended ng_ and NG_ to everything which I thought was rather
silly (but the BlueZ include files were not any friendlier so everybody is
incompatible with everybody else, annoyingly)

no SDP tools as yet, will have to look at that soonish. I have only really
tested sending data back and forth to myself which seemed to work fine
rather than talking to generic devices (my phone is playing up and I lent
my headset to somebody else, will have to get that back when I work out
SDP querying). Also I have not implemented any l2cap flow control as yet
and I'm not sure how much I need to do there. Also I recall when I did try
connections to my headset it wanted Link Keys and PIN codes which I didnt
do anything with yet (userland stuff - see btd)

to enable incoming connections, you set pscan (Page Scan) and to make a
device discoverable you set iscan (Inquiry Scan). Also to accept HCI level
connections you must have btd running (as root) which monitors devices and
picks up connections. I used l2 to test the l2cap connections ("l2" for
listening, and "l2 datatosend" to connect and send data - you would need
to hardcode the device addresses as there is no name/bdaddr lookup or
mapping available as yet - libbt probably)

All is subject to change as every step forward I take seems to involve
going back and changing my previous assumptions :) and eventually I
decided that if it worked I would leave it and will go back to neaten it
up later (HCI ioctl, 'route finding' & memo code all is a bit funny) but I
think the general shape is coming along.

I would hope that now the API is becoming useable then I can use a lot of
the user level tools (from FreeBSD/BlueZ) with little changes (I didnt
always like their choices, but) - hcidump is available in
pkgsrc/wip/hcidump and was fairly easy to fix up (its the FreeBSD version
- the BlueZ one is more comprehensive but needed more work)

so, like I say - any comments welcomed..  this is not the end, or even the
beginning of the end but its getting near the end of the beginning..

iain