← Back to team overview

ubuntu-phone team mailing list archive

Re: RFC- Having a bluetooth service to handle pairing

 

On 29.07.2015 17:52, Tony Espy wrote:
On 07/28/2015 11:28 AM, Simon Busch wrote:
On 28.07.2015 17:20, Tony Espy wrote:
On 07/28/2015 10:14 AM, Sebastien Bacher wrote:
Hey there,

Currently the only bluetooth agent available in ubuntu touch is
implemented in system settings. Which means the settings application
need to be open for bluetooth pairing to work.

Is this the same on desktop ( ie. pairing only works when the
gnome-bluetooth-settings app is running )?

We received some bugs reports suggesting that the is a need for having
request handled at any time because that's the most robust things to do
and the less confusing for users (ideally known/trusted device would
always be able to auto reconnect, but it seems that in practice
sometime
the trusted link is lost and the system need to prompt again, also
other
action are done in settings which make the pairing less reliable)
https://launchpad.net/bugs/1474296

To address this issue we are thinking about moving the auth agent out
from system settings to be a standalone service. We are going to start
working on that but wanted to check first if anyone feeling strongly
against it. The service might lead to a bit more power usage, but it
would only be active if bluetooth is on and things like visibility
would
probably be configurable as well.

Has anyone looked at the plugin architecture in Bluez?  From a quick
look, this appears to be a mechanism to extend the functionality of
bluetoothd ( the main Bluez daemon ).

Yeah you can do something like this directly in bluetoothd but I would
try to avoid this if we write such a service with things like OBEX or
other things in mind with respecting that we have to handle several
things as long as our apps can't do things in the background.

So before we get really deep here, has anyone written down the use
cases/user stories that this component is supposed to handle?

When I first read Seb's email, my assumption was that any pairing that
required a PIN would be handled by system settings, and that the PIN
associated with a particular device would be saved in a similar manner
to how NM handles access point keys/passphrases ( vs. re-prompting for
the PIN every time the device auto-pairs ).

I took a quick look at:

https://wiki.ubuntu.com/Bluetooth

...and it doesn't seem to cover how auto-pairing should work for devices
that require a PIN.

For devices that don't require a PIN, re-pairing seems to work fine
without system settings being displayed ( at least it works with my BT
earphones ).

There is actually no re-pairing. Pairing happens only once and when device is paired it is directly connected without doing any pairing. With Secure Simple Pairing there are multiple ways how to archive a bond (that is what the result of pairing is). With Just-Works it is even possible to pair with a PIN or passkey. However as Tony says we should maybe reevaluate the different use cases and make sure our implementation matches them. For example bluetooth devices with bluetooth > 2.1 supports SSP which uses passkeys rather than PINs which are digits only and can be longer than 6 ...

regards,
Simon



Follow ups

References