>> ... 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.
