Hi everyone, any updates on this issue? This bug completely blocks our feature.

The bluez stack has been switched to 5.44 in 9540.0.0. (https://chromium-review.googlesource.com/#/c/470147/) But this problem occurs in 9532.0.0. Hence, it is not related with the bluez upgrade.

We do not update the related dbus methods in bluez or the interval setting methods in kernel recently. Rahul, are you aware of any recent related changes in chrome?

Hi, Ryan, as you said "All of these values used to work a few days ago."
Is it possible that you could try with an older chrome version and see if it still breaks?  Thanks!

Sonny could you pick this up? This is a high priority to fix in 60.

AFAIK, no changes in Chrome have actually 'landed' - we have a large WIP CL which redesigns advertising but that hasn't landed yet.

Hi Ryan, please use the latest test image. The SetAdvertisingInterval method should work.

Details below:

I looked into this issue today. The bluetooth stack uprev consisted of 2 stages. The 1st stage was the uprev of user space bluez to 5.44. This was done around April 19 (https://chromium-review.googlesource.com/#/c/469436/). The 2nd stage was the uprev of four kernel versions, and was done around May 11 (https://chromium-review.googlesource.com/#/c/470147/). There were some interface changes between the user space bluez and the kernel. Hence, that is why we see the dbus failure. Using images built after May 11 should work correctly.

Hi Sonny, when we uprev to bluez 5.44, we saw some upstream patches about advertising dbus interface. Could you check whether chrome needs to modify as well? To verify this, please check if you could correctly register an advertisement with both "manufacturer data" and "service data".

Specifically, the signatures of manufacturer data and service data have been enforced. If there are any problems, please check the following two CLs in bluez.

commit 758dae03725ed7a1138d848aad940a73bbf5d659
core/advertising: Fix not parsing data properly

commit d356a6242be9a1aba2cca871b79618e3b28a5ec2
core/advertising: Fix crash when passing invalid dictionary

In my case, I need to modify our autotest for BLE advertising to accommodate the CLs. Please refer to our autotest patch "bluetooth: fix advertising data format" (https://chromium-review.googlesource.com/#/c/485540/3/client/cros/bluetooth/advertisement.py).

Hi Joseph,

Sorry for the delayed response! On the latest images and versions of Chrome, we're no longer seeing this issue -- thanks! :)

Sidenote: Do you happen to know if those commits you mentioned in #7 might have caused  crbug.com/725349 ?

Hi Ryan, it is good to hear that the latest image works for you!

As for advertisement registration, that is what was mentioned in Comment#7 -- Specifically, the signatures of manufacturer data and service data have been enforced by upstream. The signatures were not enforced before and hence we might not use the correct expected types before without being complained. Now, correct data types must be used. Otherwise, advertisement registration would fail.

Sonny, could you help check the adv registration code in chrome to see if the signatures for manufacturer data and service data are correct?

Hi Joseph -- I'd be glad to help debug this registration issue. Let's move all discussion to  crbug.com/725349 .