In article <1134003326.830023.9703.nullmailer@galant.ukfsn.org>,
Iain Hibbert  <plunky@rya-online.net> 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.
>
>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..

This is great. We've been missing bluetooth for a long time. I will take
a look at this over the weekend.

Thanks,

christos