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

The pairing case seem to be "enough" for what produce as device. As we just have devices which are marked with IO capability KeyboardDisplay (phones, tablets, PCs) we normally always end up with passkey/pin entry.

However if we take the bluetooth spec right we need to differentiate between initiator and receiver as according to the mapping table in Core 4.2 Vol 3, Part H 2.3.5.1 one side displays the PIN where the other inputs it (which can be solved with entering the same PIN on both sides too but we should try to reach a common behavior so the user doesn't get confused). BlueZ already supports all these through its agent dbus interface and we should respect those parts when they're called.

From what it looks in the ubuntu-system-settings code we nowadays don't support the DisplayPinCode call from BlueZ which is relevant for Bluetooth devices not supporting SSP (those using Bluetooth < 2.1). Will file a bug for this.

regards,
Simon



Follow ups

References