--t4apE7yKrX2dGgJC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
|=20
| 	homepages.rya-online.net/plunky/netbt.html
|=20
| 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)
|=20
| 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.

|=20
| 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)
|=20
| 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 :-(

|=20
| 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.
|=20
| incoming HCI packets are dealt with in hci_event.c and hci_link.c and is
| driven entirely from a soft interrupt.
|=20
| the l2cap API (from above) is l2cap_upper.c
|=20
| hci RAW socket is hci_socket.c
|=20
| 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.
|=20
| btconfig is basic but works and fairly easy to extend
|=20
| 	btconfig bt3c0 name "My Computer" pscan -iscan
| 		<set device name, set pscan, unset iscan>
|=20
| 	btconfig -s
| 		<print stats for all devices>
|=20
| 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.
|=20
| 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.

|=20
| 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)
|=20
| 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)
|=20
| 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)
|=20
| 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.
|=20
| 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

--t4apE7yKrX2dGgJC
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDl5PdZPqyxs9FH4QRAtWsAJ4gcCAsgwJMAPq0wZoI0rKiuRnRfgCeNHv+
SUmft2xNLzUKhu3d6U6mIj4=
=sN2A
-----END PGP SIGNATURE-----

--t4apE7yKrX2dGgJC--