[9fans] bluetooth
lyn...@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
Re: [9fans] bluetooth
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'.
Re: [9fans] bluetooth
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.
Re: [9fans] bluetooth
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?
Re: [9fans] bluetooth
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.
Re: [9fans] bluetooth
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.
Re: [9fans] bluetooth
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?
Re: [9fans] bluetooth
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;
pgp0z43OfWlPB.pgp
Description: PGP signature
Re: [9fans] bluetooth
... 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.
Re: [9fans] bluetooth
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
Re: [9fans] bluetooth
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).
Re: [9fans] bluetooth
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).
Re: [9fans] bluetooth
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
Re: [9fans] bluetooth
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.
Re: [9fans] bluetooth
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.
Re: [9fans] bluetooth
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.
Re: [9fans] bluetooth
aux/listen1 bt!*!77 /bin/exportfs import -A bt!00123456789A!77 / /n/blue beautiful!
Re: [9fans] bluetooth
import -A bt!00123456789A!77 / /n/blue what does the device id discovery look like?
Re: [9fans] bluetooth
If it's useful, I'd love to beta test or alpha test or whatever. thanks a lot for your effort!
Re: [9fans] bluetooth
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)
Re: [9fans] bluetooth
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
[9fans] bluetooth
anyone looked at this or given it any thought?
Re: [9fans] bluetooth
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.
Re: [9fans] bluetooth
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?
