New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 739883 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Tether does not wait for advertisements to be (un)registered

Project Member Reported by hansberry@chromium.org, Jul 6 2017

Issue description

See logs:

[4252:4252:0706/104209.428470:INFO:ble_advertiser.cc(94)] Advertisement registered. Device ID: "CAESR...0qr4=", Service data: 0x8751930c
[4252:4252:0706/104209.431666:INFO:ble_advertiser.cc(94)] Advertisement registered. Device ID: "CAESR...NAQ==", Service data: 0x69d67cd0
[4252:4252:0706/104221.179632:INFO:ble_connection_manager.cc(336)] Received advertisement - Device ID: "CAESR...NAQ==". Starting authentication handshake.
[4252:4252:0706/104221.187904:INFO:bluetooth_low_energy_weave_client_connection.cc(186)] Creating GATT connection with 7B:A7:F1:43:DD:7A
[4252:4252:0706/104221.265689:INFO:ble_connection_manager.cc(462)] Connection attempt timeout - Device ID "CAESR...0qr4="
[4252:4252:0706/104221.268618:INFO:ble_connection_manager.cc(499)] Status change - Device ID: "CAESR...0qr4=": [connecting] => [disconnected]
[4252:4252:0706/104221.268743:INFO:message_transfer_operation.cc(114)] Connection attempt failed for device with ID CAESR...0qr4=. Number of failures so far: 1
[4252:4252:0706/104221.268830:INFO:ble_connection_manager.cc(430)] Attempting connection - Device ID: "CAESR...0qr4="
[4252:4252:0706/104221.270242:INFO:ble_connection_manager.cc(499)] Status change - Device ID: "CAESR...0qr4=": [disconnected] => [connecting]
[4252:4270:0706/104221.274976:WARNING:exported_object.cc(215)] Unknown method: message_type: MESSAGE_METHOD_CALL
destination: :1.67
path: /org/chromium/bluetooth_advertisement/444c2be86dd24742bf04580c9d3e4af3
interface: org.freedesktop.DBus.ObjectManager
member: GetManagedObjects
sender: :1.31
serial: 2688

[4252:4252:0706/104221.276567:ERROR:bluetooth_advertisement_bluez.cc(52)] Error while registering advertisement. error_name = org.bluez.Error.Failed, error_message = Failed to register advertisement
[4252:4252:0706/104221.276716:ERROR:ble_advertiser.cc(103)] Error registering advertisement. Device ID: "CAESR...0qr4=", Service data: 0x8751930c, Error code: 1

The connection attempt to the host device, "CAESR...0qr4=", (a 5X) times out, the advertisement to it is unregistered, but then an advertisement to it is immediately registered again, resulting in error code 1, ERROR_ADVERTISEMENT_ALREADY_EXISTS.

We are not waiting on the SuccessCallback for advertisement unregistration before attempting to register the same advertisement. See here: https://cs.chromium.org/chromium/src/chromeos/components/tether/ble_advertiser.cc?sq=package:chromium&l=42 
 
Mergedinto: 736510
Status: Duplicate (was: Available)
As discussed offline, this issue is likely due to an error when the Bluetooth stack starts up. Duping to that bug instead.
Status: Available (was: Duplicate)
Reopening.

More context: This log was captured after a crash. Magic Tether successfully registered advertisements after the crash (seen in the first 2 lines). It then unregistered an advertisement, and immediately tried to re-register that advertisement without waiting for it to unregister -- causing the "already exists" error.
Owner: khorimoto@chromium.org
Status: Started (was: Available)
Project Member

Comment 4 by bugdroid1@chromium.org, Jul 12 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3b45b11eb7575d7e35ff53431dd675e83f428772

commit 3b45b11eb7575d7e35ff53431dd675e83f428772
Author: khorimoto <khorimoto@chromium.org>
Date: Wed Jul 12 19:08:37 2017

[CrOS Tether] Do not register a new Bluetooth advertisement until any previous identical advertisement has been unregistered.

This fixes the following issue:
  (1) BleAdvertiser starts advertising to device A.
  (2) BleAdvertiser stops advertising to device A. The advertisement starts its asynchyronous unregistration flow.
  (3) BleAdvertiser starts advertising to device A again, but the previous advertisement has not yet been fully unregistered.

After this fix, BleAdvertiser will wait for the previous advertisement to be unregistered in step (3), ensuring that we do not run into the ERROR_ADVERTISEMENT_ALREADY_EXISTS error.

BUG=672263, 739883 

Review-Url: https://codereview.chromium.org/2972263002
Cr-Commit-Position: refs/heads/master@{#486047}

[modify] https://crrev.com/3b45b11eb7575d7e35ff53431dd675e83f428772/chromeos/components/tether/ble_advertiser.cc
[modify] https://crrev.com/3b45b11eb7575d7e35ff53431dd675e83f428772/chromeos/components/tether/ble_advertiser.h
[modify] https://crrev.com/3b45b11eb7575d7e35ff53431dd675e83f428772/chromeos/components/tether/ble_advertiser_unittest.cc

Owner: hansberry@chromium.org
I landed part one of this fix; reassigning this issue to Ryan as he's submitting another CL to work around this issue.
Summary: Tether does not wait for advertisements to be (un)registered (was: Tether does not wait for advertisements to be unregistered before re-registering them)
Project Member

Comment 7 by bugdroid1@chromium.org, Jul 13 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/69a9c3246a397a04f587953ead0269019ab851c0

commit 69a9c3246a397a04f587953ead0269019ab851c0
Author: Ryan Hansberry <hansberry@chromium.org>
Date: Thu Jul 13 23:43:59 2017

Tether: Create a workaround for BLE advertisements left dangling.

Because the registration of BluetoothAdvertisements is asynchronous,
it is possible for the object which registered it (in this case,
a BleAdvertiser::IndividualAdvertisement) to have been destroyed by
the time the BluetoothAdvertisement finished registering. Due to
crbug.com/741050, this results in a BluetoothAdvertisement without
an owner to unregister it eventually, leaving it permanently dangling.

This CL works around the issue (until it is resolved) by creating a
static method which is available when the registration callback
fires. If the IndividualAdvertisement is destroyed when registration
is finished, the BluetoothAdvertisement is unregistered.

Bug:  739883 
Change-Id: I33f210f3bc89504ba670387460b3ffe2ba3fdcf1
Reviewed-on: https://chromium-review.googlesource.com/567561
Commit-Queue: Ryan Hansberry <hansberry@chromium.org>
Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486543}
[modify] https://crrev.com/69a9c3246a397a04f587953ead0269019ab851c0/chromeos/components/tether/ble_advertiser.cc
[modify] https://crrev.com/69a9c3246a397a04f587953ead0269019ab851c0/chromeos/components/tether/ble_advertiser.h
[modify] https://crrev.com/69a9c3246a397a04f587953ead0269019ab851c0/chromeos/components/tether/ble_advertiser_unittest.cc

Status: Fixed (was: Started)

Comment 9 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment