This is great stuff.  It is also likely that we will be contributing to
BT development in some form, either by working on it ourselves or
funding outside development.  I know that my management has broached the
topic with Wasabi, so there could be more engineering cycles thrown at
BT soon.

(We're most interested in BT for 3G networking and for HID devices.)

    -- Garrett

Rui Paulo wrote:

>On 2005.12.08 00:55:26 +0000, Iain Hibbert wrote:
>| 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.
>
>Yes, since we really need a bluetooth stack, thus sys/netbt makes sense.
>
>| 
>| 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 :)
>
>My father has an USB dongle and he can lend it to me for sometime
>(until I get my own), but unfortunately I will only see him in T minus
>2 weeks :-(
>
>| 
>| 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.
>
>I didn't look closely but I suppose we should aim at separating them.
>
>| 
>| 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)
>
>I think we can work together and turn this into some mature form
>and then integrating it in NetBSD. I don't know the overall opinion
>about Bluetooth but personally I would like to see NetBSD supporting it.
>
>Regards,
>
>		-- Rui Paulo
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134