anyone looked at this or given it any thought?
On Sep 22, 2009, at 3:34 PM, Skip Tavakkolian wrote: > anyone looked at this or given it any thought? I was going to check into it after I did some tests in the audio system. Although I probably won't finish my tests till early-mid october. > >
A very superficial glance a long time ago suggested that it was a
twisty little maze of de-facto and de-vulgus standards.
i.e. the death of a thousand committees.
Then there's the hardware ...
On 22 Sep 2009, at 20:34, Skip Tavakkolian wrote:
> anyone looked at this or given it any thought?
>
>
> anyone looked at this or given it any thought?
I've been working on a bluetooth implementation which should be
ready for initial release soon. Just the core communication layers
(usb-hci transport, hci, l2cap, rfcomm), and fairly rudimentary:
I've tried to pick a minimal useful subset rather than support
the whole 1420-page Core V2.1+EDR standard.
The interface follows the normal Plan 9 /net model, so the usual
dial/announce/listen operations work pretty much as expected,
and you can do things like:
aux/listen1 bt!*!77 /bin/exportfs
import -A bt!00123456789A!77 / /n/blue
A bit of tweaking to cs(8) would allow the use of "friendly"
device names in place of 12-hexdigit bluetooth device addresses.
> A very superficial glance a long time ago suggested that it was a > twisty little maze of de-facto and de-vulgus standards. > i.e. the death of a thousand committees. The core standard (defining the communication layers) is actually not too bad, compared to some I've had to look at. It's huge, but a lot of it is describing low-level radio stuff (below the hci layer) which your bluetooth chip takes care of. All the "profiles" (application layers) have their own separate standards documents, and there indeed is a morass of (non)design by committee. > Then there's the hardware ... Maybe I was lucky, but my random choice of development hardware (a cheap generic usb dongle with a CSR chip) has seemed to behave just as the spec says. Of course there have been surprises, but so far these have been where the spec was ambiguous and my guess didn't match the firmware designer's guess.
> aux/listen1 bt!*!77 /bin/exportfs
> import -A bt!00123456789A!77 / /n/blue
beautiful!
> import -A bt!00123456789A!77 / /n/blue
what does the device id discovery look like?
If it's useful, I'd love to beta test or alpha test or whatever. thanks a lot for your effort!
> what does the device id discovery look like?
At present:
echo inquiry M N >/net/bt/ctl
(spend up to M seconds looking for up to N devices)
cat /n/bt/devices
(see what devices have been found)
> echo inquiry M N >/net/bt/ctl
> (spend up to M seconds looking for up to N devices)
> cat /n/bt/devices
> (see what devices have been found)
the application i have in mind inventories all device id's it sees
with a time stamp. i need to measure the flow between two endpoints
based on the id/timestamp. i was thinking of something like this:
while (sleep 1) {
echo `{ls /net/bt/ids}^'@'^`{date -n}
}
i've not considered the pros/cons of each approach.
thank you for doing this. like nemo, i'd like to offer testing.
> thank you for doing this. like nemo, i'd like to offer testing.
To echo nemo and skip, I do own one USB bluetooth radio and many
mobile handsets. Count me in, if you wish.
++L
>> cat /n/bt/devices >> (see what devices have been found) Typo - should be /net/bt/devices - currently gives you device address, class, and friendly name for all "known" devices (see below). First on list is self. term% cat /net/bt/devices 00025b0011bf 020104 'atom' 00236c9dd69f 38010c 'Richard Miller’s MacBook' > the application i have in mind inventories all device id's it sees > with a time stamp. What do you mean exactly by "sees"? A device may be known because it responded to an inquiry (probe for all devices) or a page (probe for specific device), or because it sent you an inquiry or a page, or because you paired with the device at some time in the past and have a stored link key for it. [A device may be set to respond to page but not inquiry. Or vice versa.] > while (sleep 1) { > echo `{ls /net/bt/ids}^'@'^`{date -n} > } The hardware can automatically do periodic inquiry scans in the background. I could add a command 'inquiry auto N' to enable this (but I guess you would still need a 'sleep' loop to look at the devices file). Advice sought: 1. Would it be helpful to have a timestamp in the devices record to give the time the device was last seen (for some value of "seen")? 2. When should a device disappear from the /net/bt/devices list?
[-- Attachment #1: Type: text/plain, Size: 2227 bytes --] On Thu, Sep 24, 2009 at 09:22:17AM +0100, Richard Miller wrote: > What do you mean exactly by "sees"? A device may be known > because it responded to an inquiry (probe for all devices) or a > page (probe for specific device), or because it sent you an inquiry > or a page, or because you paired with the device at some time in > the past and have a stored link key for it. [A device may be set Shouldn't factotum be in charge of storing keys? Or do you mean just keys that happen to be resident in the stack right now? > to respond to page but not inquiry. Or vice versa.] > > > while (sleep 1) { > > echo `{ls /net/bt/ids}^'@'^`{date -n} > > } > > The hardware can automatically do periodic inquiry scans in the > background. I could add a command 'inquiry auto N' to enable this > (but I guess you would still need a 'sleep' loop to look at the > devices file). > > Advice sought: > 1. Would it be helpful to have a timestamp in the devices record to > give the time the device was last seen (for some value of "seen")? > 2. When should a device disappear from the /net/bt/devices list? How about exposing things as an ndb db so that we can add fields as the need arises? mac=00112233445566 name="Friendly Name" !secret=0x... lastseen=timestamp active=rfcomm3, sdp=pan,rfcomm,...,... (that might be a bad example, if sdp is done by a separate daemon, e.g.; am just musing). What about letting me set a stored key by writing a line into this as a single write of "mac=... !secret=0x..." ala factotum's ctl file? Oh hey... why not make the file also act like the sound mixers and jccfs journals? That is, just stream events out to readers, starting with a full enumeration and then updates, then the "you are about to block" empty read, then block until the next scan or timeout which changes something. You can give an advisory signal (mac=... gone= or somesuch) that a device should be considered gone (and purge it from the list you'd report to a fresh client) after some small time interval... something between 5 and 30 seconds seems reasonable to me? People watching the event stream are free to do their own thing. Does that seem reasonable? --nwf; [-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]
>> ... or because you paired with the device at some time in >> the past and have a stored link key for it. > > Shouldn't factotum be in charge of storing keys? Or do you mean just > keys that happen to be resident in the stack right now? No, I mean keys which are kept in non-volatile store inside the bluetooth chip. The BT firmware kindly does this for you. This means when you buy a secondhand phone, put a new SIM card in it, and wipe its memory, it may still be paired with random devices from its previous life. > How about exposing things as an ndb db so that we can add fields as the > need arises? > mac=00112233445566 name="Friendly Name" !secret=0x... lastseen=timestamp > active=rfcomm3, sdp=pan,rfcomm,...,... > (that might be a bad example, if sdp is done by a separate daemon, e.g.; > am just musing). I think this is mixing too many unrelated things together. Sdp is another layer (like dns), and if you want to see active connections you can use netstat. /net/bt/devices is simply for relating names to addresses, like /net/arp. > What about letting me set a stored key by writing a line into this as a > single write of "mac=... !secret=0x..." ala factotum's ctl file? Where would you get the key from? Link keys are generated internally during the pairing transaction between devices. The PIN used for pairing is supplied by the user with a command to /net/bt/ctl, but this will be different each time so there's no point giving it to factotum. > You can give an advisory signal (mac=... gone= or somesuch) that a device > should be considered gone (and purge it from the list you'd report to a > fresh client) after some small time interval... something between 5 and 30 > seconds seems reasonable to me? People watching the event stream are free > to do their own thing. I can't see a compelling application for this but maybe I'm unimaginative. If you are connected to a device and it disappears you'll get a hangup.
> 00236c9dd69f 38010c 'Richard Miller’s MacBook'
I was going to comment that you should use %q instead of '%s'
but now I notice that the apostrophe is 0x2019 not a simple '.
Does Bluetooth specify UTF-8 as the string encoding sent over
the network?
Russ
> I was going to comment that you should use %q instead of '%s' I do, of course. The funny apostrophe was MacOS's idea. > Does Bluetooth specify UTF-8 as the string encoding sent over > the network? No, just that the device name is encoded as UTF-8 (up to 248 octets).
> What do you mean exactly by "sees"? A device may be known
> because it responded to an inquiry (probe for all devices)
all devices that are listening on inquiry scan channels and respond to
inquiry requests. (i'm just learning the details and my terminology
may be a bit off).
Fantastic work Richard, I too will be very interested in playing with this once you are ready. The only one thought - probably not mentioned as it is so obvious, it would be neat if the plumber and thus auth/fgui could be pressed into service for entering the pairing PIN. -Steve
Thanks a million for all your work on this:
it means I'll probably be running plan9 seriously soon:-).
To be selfish for a moment ...
Presumably there's still a medium sized asteroid of pain to go through
to get something like,
say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...)
working sensibly?
Oh, and we'll need more drivers which will need to be more complex and
more efficient and less buggy
while driving more, and more divergent hardware which is becoming ever
more complex and bigger and buggier,
of course.
OTOH, of course, we do at least have the wonderfully clean plan9 view
of all this contortionous mess,
so at least when I need to push an avrcp driver onto my stack,
I can manipulate and see the hideous vipers nest in userland and prod
it with rc.
Plus, of course, it'll be totally dandy for connecting my plan9
wristputer to my plan9 briefcase.
Well done again.
D
On 23 Sep 2009, at 15:48, Richard Miller wrote:
>> A very superficial glance a long time ago suggested that it was a
>> twisty little maze of de-facto and de-vulgus standards.
>> i.e. the death of a thousand committees.
>
> The core standard (defining the communication layers) is actually
> not too bad, compared to some I've had to look at. It's huge, but
> a lot of it is describing low-level radio stuff (below the hci layer)
> which your bluetooth chip takes care of.
>
> All the "profiles" (application layers) have their own separate
> standards documents, and there indeed is a morass of (non)design
> by committee.
>
>> Then there's the hardware ...
>
> Maybe I was lucky, but my random choice of development hardware
> (a cheap generic usb dongle with a CSR chip) has seemed to behave
> just as the spec says. Of course there have been surprises, but
> so far these have been where the spec was ambiguous and my guess
> didn't match the firmware designer's guess.
>
>
>> What do you mean exactly by "sees"? ...
>
> all devices that are listening on inquiry scan channels and respond to
> inquiry requests.
It looks like your requirement might be satisfied by one or
the other of these things in the /net/bt/devices record:
- a discoverable (ie "responded to most recent inquiry") flag
- a timestamp for last inquiry response received (1 second resolution?)
I'm reluctant to remove devices altogether when they don't
respond to inquiry, because it may still be possible to
connect to a non-discoverable device by paging its address.
> it would be neat if the plumber and thus auth/fgui could be pressed
> into service for entering the pairing PIN.
I don't quite see the connection between plumber and fgui - doesn't
fgui just read directly from /mnt/factotum/needkey?
At present there's a needkey-like mechanism for PINs - the equivalent
of fgui is this simple rc loop:
while (bd=`{read </net/bt/pinreq}) {
echo -n enter PIN for device `{grep $bd /net/bt/devices} ' : '
pin=`{read}
~ $pin '' || echo pin $bd $pin >/net/bt/ctl
}
But now you mention it, using the plumber seems a good idea, so we
could pop up a new window to ask for a PIN when needed.
> Presumably there's still a medium sized asteroid of pain to go through > to get something like, > say, my bluetooth stereo-phones+headset(A2DP/AVRCP/... ... ...) > working sensibly? A2DP will need synchronous connections which aren't implemented yet (sorry). AVRCP itself looks straightforward, but it's mostly just a wrapper for the AV/C command set. The spec for AV/C looks well enough defined, so go ahead! > Oh, and we'll need more drivers which will need to be more complex and > more efficient and less buggy s/more complex/simpler/ -- we are talking about Plan 9, remember?
you could just set the mtime to the time of the last successful
operation on that device
>>>What do you mean exactly by "sees"? ...
>>>
>>>
>>all devices that are listening on inquiry scan channels and respond to
>>inquiry requests.
>>
>>
>
>It looks like your requirement might be satisfied by one or
>the other of these things in the /net/bt/devices record:
>
>- a discoverable (ie "responded to most recent inquiry") flag
>- a timestamp for last inquiry response received (1 second resolution?)
>
>I'm reluctant to remove devices altogether when they don't
>respond to inquiry, because it may still be possible to
>connect to a non-discoverable device by paging its address.
>
>
>
>
Now that I have a little experience, I've formed an opinion > Advice sought: > 1. Would it be helpful to have a timestamp in the devices record to > give the time the device was last seen (for some value of "seen")? Yes; this would be a good feature. > 2. When should a device disappear from the /net/bt/devices list? it would be good if this was settable. i think the value depends on the application and user behavior. at a starbucks they might hang around, but along a walkway it might be the length of time a person walks 30'.
lyndon@orthanc.ca: > Bluetooth (and BLE) support woould be *very* nice to have. I have a native bluetooth host implementation for Plan 9, not ported from anything (it's written from scratch based on published bt specs.) I don't regard it as sufficiently debugged for a release ... it's missing some important error handling (mandatory retries to recover from poor reception) and it just plain doesn't work for some of the dongles I've tried. I don't know whether it's compatible with BLE (which didn't exist at the time I wrote it). Contact me off list if you'd like a copy. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T69704162cbe0c04a-Mf8839883c089cb58afb527cf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription