Unreliable LE advertisement registration through BlueZ advertising API

Unreliable LE advertisement registration through BlueZ advertising API

[Othman, Ossama]

Hi,

I'm trying to leverage the LE advertising API in BlueZ 5.31 but
advertisement registration sometimes fails with an Invalid Parameters
error:

Jun 24 21:56:06 orion bluetoothd[21940]:
src/advertising.c:register_advertisement() RegisterAdvertisement
Jun 24 21:56:06 orion bluetoothd[21940]:
src/advertising.c:advertisement_create() Adding proxy for
/org/iotivity/gatt/advertisement0
Jun 24 21:56:06 orion bluetoothd[21940]:
src/advertising.c:register_advertisement() Registered advertisement at
path /org/iotivity/gatt/advertisement0
Jun 24 21:56:06 orion bluetoothd[21940]:
src/advertising.c:parse_advertising_service_uuids() Adding
ServiceUUID: ADE3D529-C784-4F63-A987-EB69F70EE816
Jun 24 21:56:06 orion bluetoothd[21940]:
src/advertising.c:refresh_advertisement() Refreshing advertisement:
/org/iotivity/gatt/advertisement0
Jun 24 21:56:06 orion bluetoothd[21940]: Failed to add advertisement:
Invalid Parameters (0x0d)

It looks like my LEAdvertisement1 object itself is fine since BlueZ
doesn't complain about it. There are times when registration succeeds,
as well.

Adding an advertisement with the same data through the btmgmt tool
will fail in the same way if I provide a bogus instance ID:

[mgmt]# add-adv -c -g -u ADE3D529-C784-4F63-A987-EB69F70EE816 0
Add Advertising failed with status 0x0d (Invalid Parameters)

but is fine if I provide a suitable instance ID:

[mgmt]# add-adv -c -g -u ADE3D529-C784-4F63-A987-EB69F70EE816 1
Instance added: 1

As a sanity check I ran test/example-advertisement but it fails for
other reasons:

$ ./example-advertisement
Failed to register advertisement: org.bluez.Error.Failed: Failed to
parse advertisement

The log output
Jun 25 11:04:43 void-dev bluetoothd[758]:
src/advertising.c:register_advertisement()
RegisterAdvertisement
Jun 25 11:04:43 void-dev bluetoothd[758]:
src/advertising.c:advertisement_create() Adding proxy for
/org/bluez/example/advertisement0
Jun 25 11:04:43 void-dev bluetoothd[758]:
src/advertising.c:register_advertisement() Registered advertisement at
path /org/bluez/example/advertisement0
Jun 25 11:04:43 void-dev dbus[793]: [system] Rejected send message, 1
matched rules; type="method_call", sender=":1.2" (uid=0 pid=758
comm="/usr/libexec/bluetooth/bluetoothd --experimental -")
interface="org.freedesktop.DBus.Properties" member="GetAll" error
name="(unset)" requested_reply="0" destination=":1.222" (uid=1000
pid=13905 comm="/usr/bin/python ./example-advertisement ")
Jun 25 11:04:43 void-dev bluetoothd[758]: Failed to read "Type"
property of advertisement

Any ideas on what could be causing the intermittent advertisement
registration failures when using the BlueZ D-Bus advertising API?

Thanks,
-Ossama

Re: Unreliable LE advertisement registration through BlueZ advertising API

[Tedd Ho-Jeong An]

Hi Ossama

On Thu, 25 Jun 2015 11:12:20 -0700
"Othman, Ossama" <ossama.othman@intel.com> wrote:

> Hi,
> 
> I'm trying to leverage the LE advertising API in BlueZ 5.31 but
> advertisement registration sometimes fails with an Invalid Parameters
> error:
> 
> Jun 24 21:56:06 orion bluetoothd[21940]:
> src/advertising.c:register_advertisement() RegisterAdvertisement
> Jun 24 21:56:06 orion bluetoothd[21940]:
> src/advertising.c:advertisement_create() Adding proxy for
> /org/iotivity/gatt/advertisement0
> Jun 24 21:56:06 orion bluetoothd[21940]:
> src/advertising.c:register_advertisement() Registered advertisement at
> path /org/iotivity/gatt/advertisement0
> Jun 24 21:56:06 orion bluetoothd[21940]:
> src/advertising.c:parse_advertising_service_uuids() Adding
> ServiceUUID: ADE3D529-C784-4F63-A987-EB69F70EE816
> Jun 24 21:56:06 orion bluetoothd[21940]:
> src/advertising.c:refresh_advertisement() Refreshing advertisement:
> /org/iotivity/gatt/advertisement0
> Jun 24 21:56:06 orion bluetoothd[21940]: Failed to add advertisement:
> Invalid Parameters (0x0d)
> 
> It looks like my LEAdvertisement1 object itself is fine since BlueZ
> doesn't complain about it. There are times when registration succeeds,
> as well.
> 
> Adding an advertisement with the same data through the btmgmt tool
> will fail in the same way if I provide a bogus instance ID:
> 
> [mgmt]# add-adv -c -g -u ADE3D529-C784-4F63-A987-EB69F70EE816 0
> Add Advertising failed with status 0x0d (Invalid Parameters)
> 
> but is fine if I provide a suitable instance ID:
> 
> [mgmt]# add-adv -c -g -u ADE3D529-C784-4F63-A987-EB69F70EE816 1
> Instance added: 1
> 
> As a sanity check I ran test/example-advertisement but it fails for
> other reasons:
> 
> $ ./example-advertisement
> Failed to register advertisement: org.bluez.Error.Failed: Failed to
> parse advertisement
> 
> The log output
> Jun 25 11:04:43 void-dev bluetoothd[758]:
> src/advertising.c:register_advertisement()
> RegisterAdvertisement
> Jun 25 11:04:43 void-dev bluetoothd[758]:
> src/advertising.c:advertisement_create() Adding proxy for
> /org/bluez/example/advertisement0
> Jun 25 11:04:43 void-dev bluetoothd[758]:
> src/advertising.c:register_advertisement() Registered advertisement at
> path /org/bluez/example/advertisement0
> Jun 25 11:04:43 void-dev dbus[793]: [system] Rejected send message, 1
> matched rules; type="method_call", sender=":1.2" (uid=0 pid=758
> comm="/usr/libexec/bluetooth/bluetoothd --experimental -")
> interface="org.freedesktop.DBus.Properties" member="GetAll" error
> name="(unset)" requested_reply="0" destination=":1.222" (uid=1000
> pid=13905 comm="/usr/bin/python ./example-advertisement ")
> Jun 25 11:04:43 void-dev bluetoothd[758]: Failed to read "Type"
> property of advertisement
> 
> Any ideas on what could be causing the intermittent advertisement
> registration failures when using the BlueZ D-Bus advertising API?
> 

I had exactly same problem on FC22 with latest kernel from bluetooth-next and tip from the Bluez.
After updating the system to latest version (./sudo dnf update) then it started to work.
I think there is some issue on DBUS not the bluez.

Any way, once I run the example-advertisement script, I cannot run it again until I restart the bleutooth daemon.
This is known issue.

Hope this help.

> Thanks,
> -Ossama
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unreliable LE advertisement registration through BlueZ advertising API

[Othman, Ossama]

Hi Tedd,

Thanks for the quick follow-up!

On Thu, Jun 25, 2015 at 11:18 AM, Tedd Ho-Jeong An <tedd.an@intel.com> wrote:
> I had exactly same problem on FC22 with latest kernel from bluetooth-next and tip from the Bluez.

For reference, I'm running Kubuntu 15.04 with the 4.1 kernel
(http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-unstable/)
installed.

> After updating the system to latest version (./sudo dnf update) then it started to work.
> I think there is some issue on DBUS not the bluez.

Are you referring to the example-advertisement issue I'm seeing?  I
haven't been able to get it to run all at all, which is odd since
example-gatt-server works without problem.  AFAICT, my GDBus based LE
advertisement code is not running to D-Bus related issues since BlueZ
is able to retrieve all of the advertisement properties.  I'll crank
up gdb on bluetoothd to verify the advertisement properties.

> Any way, once I run the example-advertisement script, I cannot run it again until I restart the bleutooth daemon.
> This is known issue.

Okay, I'll keep digging.

Thanks again!
-Ossama

Re: Unreliable LE advertisement registration through BlueZ advertising API

[Luiz Augusto von Dentz]

Hi Ossama,

On Thu, Jun 25, 2015 at 10:58 PM, Othman, Ossama
<ossama.othman@intel.com> wrote:
> Hi Tedd,
>
> Thanks for the quick follow-up!
>
> On Thu, Jun 25, 2015 at 11:18 AM, Tedd Ho-Jeong An <tedd.an@intel.com> wrote:
>> I had exactly same problem on FC22 with latest kernel from bluetooth-next and tip from the Bluez.
>
> For reference, I'm running Kubuntu 15.04 with the 4.1 kernel
> (http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-unstable/)
> installed.
>
>> After updating the system to latest version (./sudo dnf update) then it started to work.
>> I think there is some issue on DBUS not the bluez.
>
> Are you referring to the example-advertisement issue I'm seeing?  I
> haven't been able to get it to run all at all, which is odd since
> example-gatt-server works without problem.  AFAICT, my GDBus based LE
> advertisement code is not running to D-Bus related issues since BlueZ
> is able to retrieve all of the advertisement properties.  I'll crank
> up gdb on bluetoothd to verify the advertisement properties.

Perhaps he is talking about missing policy, bluetooth.conf should
contain the following:

    <allow send_interface="org.bluez.GattCharacteristic1"/>
    <allow send_interface="org.bluez.GattDescriptor1"/>
    <allow send_interface="org.freedesktop.DBus.ObjectManager"/>
    <allow send_interface="org.freedesktop.DBus.Properties"/>


If it doesn't please update it and reload D-Bus service.

>> Any way, once I run the example-advertisement script, I cannot run it again until I restart the bleutooth daemon.
>> This is known issue.
>
> Okay, I'll keep digging.

That is something in the kernel Im afraid, it doesn't seems to remove
the instances properly.

> Thanks again!
> -Ossama
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Luiz Augusto von Dentz

Re: Unreliable LE advertisement registration through BlueZ advertising API

[jerico.dev]

Hi Luiz,

>>> Any way, once I run the example-advertisement script, I cannot run it again until I restart the bleutooth daemon.
>>> This is known issue.
>>
>> Okay, I'll keep digging.
>
> That is something in the kernel Im afraid, it doesn't seems to remove
> the instances properly.

is it possible to reproduce this bad behavior with the btmgmt tool? I'd 
like to have a look at it to find out the reason.

Florian

Re: Unreliable LE advertisement registration through BlueZ advertising API

[Luiz Augusto von Dentz]

Hi Florian,

On Fri, Jun 26, 2015 at 3:22 PM, jerico.dev <jerico.dev@gmail.com> wrote:
> Hi Luiz,
>
>>>> Any way, once I run the example-advertisement script, I cannot run it
>>>> again until I restart the bleutooth daemon.
>>>> This is known issue.
>>>
>>>
>>> Okay, I'll keep digging.
>>
>>
>> That is something in the kernel Im afraid, it doesn't seems to remove
>> the instances properly.
>
>
> is it possible to reproduce this bad behavior with the btmgmt tool? I'd like
> to have a look at it to find out the reason.

Check the patch I just sent.


-- 
Luiz Augusto von Dentz

Re: Unreliable LE advertisement registration through BlueZ advertising API

[jerico.dev]

On 06/26/2015 02:28 PM, Luiz Augusto von Dentz wrote:
> Hi Florian,
>
> On Fri, Jun 26, 2015 at 3:22 PM, jerico.dev <jerico.dev@gmail.com> wrote:
>> Hi Luiz,
>>
>>>>> Any way, once I run the example-advertisement script, I cannot run it
>>>>> again until I restart the bleutooth daemon.
>>>>> This is known issue.
>>>>
>>>>
>>>> Okay, I'll keep digging.
>>>
>>>
>>> That is something in the kernel Im afraid, it doesn't seems to remove
>>> the instances properly.
>>
>>
>> is it possible to reproduce this bad behavior with the btmgmt tool? I'd like
>> to have a look at it to find out the reason.
>
> Check the patch I just sent.

Nice. So in fact it was just invalid instance ids being used. What about 
the instance removal issue, did that materialize somehow?

Florian

Re: Unreliable LE advertisement registration through BlueZ advertising API

[Luiz Augusto von Dentz]

Hi Florian,

On Fri, Jun 26, 2015 at 3:36 PM, jerico.dev <jerico.dev@gmail.com> wrote:
>
>
> On 06/26/2015 02:28 PM, Luiz Augusto von Dentz wrote:
>>
>> Hi Florian,
>>
>> On Fri, Jun 26, 2015 at 3:22 PM, jerico.dev <jerico.dev@gmail.com> wrote:
>>>
>>> Hi Luiz,
>>>
>>>>>> Any way, once I run the example-advertisement script, I cannot run it
>>>>>> again until I restart the bleutooth daemon.
>>>>>> This is known issue.
>>>>>
>>>>>
>>>>>
>>>>> Okay, I'll keep digging.
>>>>
>>>>
>>>>
>>>> That is something in the kernel Im afraid, it doesn't seems to remove
>>>> the instances properly.
>>>
>>>
>>>
>>> is it possible to reproduce this bad behavior with the btmgmt tool? I'd
>>> like
>>> to have a look at it to find out the reason.
>>
>>
>> Check the patch I just sent.
>
>
> Nice. So in fact it was just invalid instance ids being used. What about the
> instance removal issue, did that materialize somehow?

It was not an issue actually, the instance is removed it just that the
userspace has to remember which id are available, Im not sure this is
a good idea though, it seems anyone can overwrite the instance id
adding its own data provided it has access to mgmt socket.


-- 
Luiz Augusto von Dentz

Re: Unreliable LE advertisement registration through BlueZ advertising API

[Othman, Ossama]

Hi Luiz,

On Fri, Jun 26, 2015 at 4:13 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Perhaps he is talking about missing policy, bluetooth.conf should
> contain the following:
>
>     <allow send_interface="org.bluez.GattCharacteristic1"/>
>     <allow send_interface="org.bluez.GattDescriptor1"/>
>     <allow send_interface="org.freedesktop.DBus.ObjectManager"/>
>     <allow send_interface="org.freedesktop.DBus.Properties"/>
>
>
> If it doesn't please update it and reload D-Bus service.

My bluetooth.conf was indeed out-of-date.  I didn't notice that the
bootstrap-configure script disabled data files by default, so they
didn't get installed with the rest of BlueZ.  With the correct
bluetooth.conf file in place I'm able to run example-advertisement.

Thanks!
-Ossama