How BLE services could be remembered?

How BLE services could be remembered?

[José Bollo]

Hello,

I observe a strange behaviour of bluez dbus interface.

I'm using Cinolink BT 4.0 USB Adapter (CSR BC8510 chipset), Bluez 5.43
on debian and/or on fedora.

When I first pair a BLE device, the services are correctly discovered
and the GATT endpoints are created (a lot).

Then I can use it as expected and it is nice. But when I turn off the
computer and restart it, things become different.

Because the devices are paired with LT key, they are still paired but
the GATT services are not availables. I can connect to the device but
it doesn't declares the GATT properties/attributes that I need. Also,
the service advertises itself without effect.

To be able to restore the attributes, I need to first remove the
device using bluetoothctl (CancelPair doesn't seems to work) and to
pair a new time.

Can you reproduce it? Is it the intended behaviour? How can I setup
the system to have GATT properties+attributes present after an
advertising? What dbus method should I call (ConnectService doesn't
works)?

Best regards

Jos=C3=A9 Bollo - Senior Software Engineer
www.iot.bzh

Re: How BLE services could be remembered?

[Luiz Augusto von Dentz]

Hi Jose,

On Thu, Dec 8, 2016 at 4:40 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wrote:
> Hello,
>
> I observe a strange behaviour of bluez dbus interface.
>
> I'm using Cinolink BT 4.0 USB Adapter (CSR BC8510 chipset), Bluez 5.43
> on debian and/or on fedora.
>
> When I first pair a BLE device, the services are correctly discovered
> and the GATT endpoints are created (a lot).
>
> Then I can use it as expected and it is nice. But when I turn off the
> computer and restart it, things become different.
>
> Because the devices are paired with LT key, they are still paired but
> the GATT services are not availables. I can connect to the device but
> it doesn't declares the GATT properties/attributes that I need. Also,
> the service advertises itself without effect.

The attributes should be saved in cache but they are only reloaded on
demand once a connection happens. Also if the database changes the
cache can be invalidated removing its attributes, this has been
changed so premature disconnections don't cause that anymore but in
case the database do actually change their attributes will be
invalidated. So if your device is known to cause premature disconnects
please try with upstream version.

> To be able to restore the attributes, I need to first remove the
> device using bluetoothctl (CancelPair doesn't seems to work) and to
> pair a new time.

CancelPair is for an ongoing pair not to actually remove an existing
one, perhaps the device is not reconnecting for some reason. Btw if
you are using privacy and the device uses directed advertising using
the identity/public address that could cause problems with
reconnections.

> Can you reproduce it? Is it the intended behaviour? How can I setup
> the system to have GATT properties+attributes present after an
> advertising? What dbus method should I call (ConnectService doesn't
> works)?

ConnectService? You mean Connect/ConnectProfile, those can be used in
case you want to force an active scanning + connect procedure,
otherwise the device shall be reconnected using passive scanning.

--=20
Luiz Augusto von Dentz

Re: How BLE services could be remembered?

[José Bollo]

Hi Luiz,

2016-12-09 10:43 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
> Hi Jose,
>
> On Thu, Dec 8, 2016 at 4:40 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wrot=
e:
>> Hello,
>>
>> I observe a strange behaviour of bluez dbus interface.
>>
>> I'm using Cinolink BT 4.0 USB Adapter (CSR BC8510 chipset), Bluez 5.43
>> on debian and/or on fedora.
>>
>> When I first pair a BLE device, the services are correctly discovered
>> and the GATT endpoints are created (a lot).
>>
>> Then I can use it as expected and it is nice. But when I turn off the
>> computer and restart it, things become different.
>>
>> Because the devices are paired with LT key, they are still paired but
>> the GATT services are not availables. I can connect to the device but
>> it doesn't declares the GATT properties/attributes that I need. Also,
>> the service advertises itself without effect.
>
> The attributes should be saved in cache but they are only reloaded on
> demand once a connection happens. Also if the database changes the
> cache can be invalidated removing its attributes, this has been
> changed so premature disconnections don't cause that anymore but in
> case the database do actually change their attributes will be
> invalidated. So if your device is known to cause premature disconnects
> please try with upstream version.

That is probably the case, the device disconnects itself after a
transaction. Its designer made it to improve battery life.

The attribute stay available by DBUS until next restart.

I'll try the upstream version and check whether attribute are
available after a restart.

(snip)

> ConnectService? You mean Connect/ConnectProfile, those can be used in
> case you want to force an active scanning + connect procedure,
> otherwise the device shall be reconnected using passive scanning.

Yes I meant ConnectProfile.

Is it preferable to use ConnectProfile instead of Connect when only
one profile is expected?
The device is always advertising. I think that I have to connect
explicitly because the connection is not automatic.

> Luiz Augusto von Dentz

Best regards
Jos=C3=A9

Re: How BLE services could be remembered?

[Luiz Augusto von Dentz]

Hi Jose,

On Fri, Dec 9, 2016 at 1:14 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wrote:
> Hi Luiz,
>
> 2016-12-09 10:43 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
>> Hi Jose,
>>
>> On Thu, Dec 8, 2016 at 4:40 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wro=
te:
>>> Hello,
>>>
>>> I observe a strange behaviour of bluez dbus interface.
>>>
>>> I'm using Cinolink BT 4.0 USB Adapter (CSR BC8510 chipset), Bluez 5.43
>>> on debian and/or on fedora.
>>>
>>> When I first pair a BLE device, the services are correctly discovered
>>> and the GATT endpoints are created (a lot).
>>>
>>> Then I can use it as expected and it is nice. But when I turn off the
>>> computer and restart it, things become different.
>>>
>>> Because the devices are paired with LT key, they are still paired but
>>> the GATT services are not availables. I can connect to the device but
>>> it doesn't declares the GATT properties/attributes that I need. Also,
>>> the service advertises itself without effect.
>>
>> The attributes should be saved in cache but they are only reloaded on
>> demand once a connection happens. Also if the database changes the
>> cache can be invalidated removing its attributes, this has been
>> changed so premature disconnections don't cause that anymore but in
>> case the database do actually change their attributes will be
>> invalidated. So if your device is known to cause premature disconnects
>> please try with upstream version.
>
> That is probably the case, the device disconnects itself after a
> transaction. Its designer made it to improve battery life.
>
> The attribute stay available by DBUS until next restart.
>
> I'll try the upstream version and check whether attribute are
> available after a restart.
>
> (snip)
>
>> ConnectService? You mean Connect/ConnectProfile, those can be used in
>> case you want to force an active scanning + connect procedure,
>> otherwise the device shall be reconnected using passive scanning.
>
> Yes I meant ConnectProfile.
>
> Is it preferable to use ConnectProfile instead of Connect when only
> one profile is expected?
> The device is always advertising. I think that I have to connect
> explicitly because the connection is not automatic.

Actually in this case it should just reconnect if the device is
advertising, so you should need to use either ConnectProfile or
Connect, actually ConnectProfile doesn't work for LE since the
profiles need GATT to be connected first and anyway the way the LE
works is that the peripheral would advertise so perhaps what is
missing is that you register an application implementing GattProfile1
interface that way bluetoothd can tell there is an application trying
to use the profile see:
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt

--=20
Luiz Augusto von Dentz

Re: How BLE services could be remembered?

[José Bollo]

Hi all,

Using the commit c64b4d9e8dc3e36672061f39a9dba19ad0fb1ef1, the issue
is sloved. Great! Thank you.

But my issue was also related to the fact that 'connected' was
received before availability of the attributes/services. The code was
disconnecting with the effect that not attributes/services coulded be
discovered.

Should I that the variable "ServicesResolved" is intended to reflect
the service resolution state? How long should I wait after being
connected for the ServiceResolved Status? Is there a way to know that
service resolution is in progress?

Best regards
Jos=C3=A9 Bollo
Jos=C3=A9 Bollo - Senior Software Engineer
www.iot.bzh



2016-12-09 14:15 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
> Hi Jose,
>
> On Fri, Dec 9, 2016 at 1:14 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wrot=
e:
>> Hi Luiz,
>>
>> 2016-12-09 10:43 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>=
:
>>> Hi Jose,
>>>
>>> On Thu, Dec 8, 2016 at 4:40 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wr=
ote:
>>>> Hello,
>>>>
>>>> I observe a strange behaviour of bluez dbus interface.
>>>>
>>>> I'm using Cinolink BT 4.0 USB Adapter (CSR BC8510 chipset), Bluez 5.43
>>>> on debian and/or on fedora.
>>>>
>>>> When I first pair a BLE device, the services are correctly discovered
>>>> and the GATT endpoints are created (a lot).
>>>>
>>>> Then I can use it as expected and it is nice. But when I turn off the
>>>> computer and restart it, things become different.
>>>>
>>>> Because the devices are paired with LT key, they are still paired but
>>>> the GATT services are not availables. I can connect to the device but
>>>> it doesn't declares the GATT properties/attributes that I need. Also,
>>>> the service advertises itself without effect.
>>>
>>> The attributes should be saved in cache but they are only reloaded on
>>> demand once a connection happens. Also if the database changes the
>>> cache can be invalidated removing its attributes, this has been
>>> changed so premature disconnections don't cause that anymore but in
>>> case the database do actually change their attributes will be
>>> invalidated. So if your device is known to cause premature disconnects
>>> please try with upstream version.
>>
>> That is probably the case, the device disconnects itself after a
>> transaction. Its designer made it to improve battery life.
>>
>> The attribute stay available by DBUS until next restart.
>>
>> I'll try the upstream version and check whether attribute are
>> available after a restart.
>>
>> (snip)
>>
>>> ConnectService? You mean Connect/ConnectProfile, those can be used in
>>> case you want to force an active scanning + connect procedure,
>>> otherwise the device shall be reconnected using passive scanning.
>>
>> Yes I meant ConnectProfile.
>>
>> Is it preferable to use ConnectProfile instead of Connect when only
>> one profile is expected?
>> The device is always advertising. I think that I have to connect
>> explicitly because the connection is not automatic.
>
> Actually in this case it should just reconnect if the device is
> advertising, so you should need to use either ConnectProfile or
> Connect, actually ConnectProfile doesn't work for LE since the
> profiles need GATT to be connected first and anyway the way the LE
> works is that the peripheral would advertise so perhaps what is
> missing is that you register an application implementing GattProfile1
> interface that way bluetoothd can tell there is an application trying
> to use the profile see:
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt
>
> --
> Luiz Augusto von Dentz

Re: How BLE services could be remembered?

[Luiz Augusto von Dentz]

Hi Jose,

On Mon, Dec 12, 2016 at 3:35 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wrote=
:
> Hi all,
>
> Using the commit c64b4d9e8dc3e36672061f39a9dba19ad0fb1ef1, the issue
> is sloved. Great! Thank you.
>
> But my issue was also related to the fact that 'connected' was
> received before availability of the attributes/services. The code was
> disconnecting with the effect that not attributes/services coulded be
> discovered.
>
> Should I that the variable "ServicesResolved" is intended to reflect
> the service resolution state? How long should I wait after being
> connected for the ServiceResolved Status? Is there a way to know that
> service resolution is in progress?

You should use ServicesResolved and wait until it becomes 1/true,
while it is false it means it is in progress, when connected, but it
should be quite fast to resolve the services once the cache is
populated.

Re: How BLE services could be remembered?

[José Bollo]

Hi all,

Few words, just to tell that it works fine now.

Thank you Luiz and Petri

Best regards
Jos=C3=A9 Bollo
Jos=C3=A9 Bollo - Senior Software Engineer
www.iot.bzh



2016-12-12 15:20 GMT+01:00 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
> Hi Jose,
>
> On Mon, Dec 12, 2016 at 3:35 PM, Jos=C3=A9 Bollo <jose.bollo@iot.bzh> wro=
te:
>> Hi all,
>>
>> Using the commit c64b4d9e8dc3e36672061f39a9dba19ad0fb1ef1, the issue
>> is sloved. Great! Thank you.
>>
>> But my issue was also related to the fact that 'connected' was
>> received before availability of the attributes/services. The code was
>> disconnecting with the effect that not attributes/services coulded be
>> discovered.
>>
>> Should I that the variable "ServicesResolved" is intended to reflect
>> the service resolution state? How long should I wait after being
>> connected for the ServiceResolved Status? Is there a way to know that
>> service resolution is in progress?
>
> You should use ServicesResolved and wait until it becomes 1/true,
> while it is false it means it is in progress, when connected, but it
> should be quite fast to resolve the services once the cache is
> populated.