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

Issue 591069 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue 596050
issue 600655

Blocking:
issue 507415



Sign in to add a comment

bluetooth: writeValue needs to be resilient to device disconnection

Project Member Reported by fbeaufort@chromium.org, Mar 1 2016

Issue description

Version 50.0.2651.0 dev (64-bit)

characteristic.writeValue should eventually fail if device is disconnected - meaning doesn't return a write response.

As you can see below, this happened to me and I'm still waiting stuck as my promise doesn't resolve/reject.


< ACL Data TX: Handle 32 flags 0x00 dlen 9                                                                                                               [hci0] 1435.807676
      ATT: Write Request (0x12) len 4
        Handle: 0x000e
          Data: 0104
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                                                   [hci0] 1435.875299
        Num handles: 1
        Handle: 32
        Count: 1
> HCI Event: Vendor (0xff) plen 7                                                                                                                        [hci0] 1436.348309
        82 12 95 40 10 36 59                             ...@.6Y         
> HCI Event: Disconnect Complete (0x05) plen 4                                                                                                           [hci0] 1436.349296
        Status: Success (0x00)
        Handle: 32
        Reason: Connection Timeout (0x08)
@ Device Disconnected: F1:6F:DE:EC:F1:D6 (2) reason 1
 
Summary: bluetooth: writeValue needs to be resilient to device disconnection (was: writeValue needs to be resilient to device disconnection)
I think this should be bluez's job. We can add logic to reject all pending promises if the device disconnects but I still think the platform, in this case bluez, should tell us if a write failed because of disconnection.
Cc: luiz.von...@intel.com
I've sent a request to BlueZ folks at http://permalink.gmane.org/gmane.linux.bluez.kernel/66791 to see how they feel about this.

ccing there Luiz Augusto von Dentz, BlueZ maintainer.

Comment 4 by mjdie...@gmail.com, Mar 2 2016

Completely agree that we need this functionality. I've seen my program hanging indefinitely at various Web Bluetooth API calls. I can start to document these to get a hold of what's going on but I believe it is similar to this issue (except also with things like connecting, discovering services etc...)
FYI, BlueZ folks replied: 

Yes, it should probably return and error so the client is not left
hanging. I will investigate how this can be fixed.
Labels: BlueZ-5.38
Owner: fbeaufort@chromium.org
Status: Assigned (was: Untriaged)
This has just been fixed in BlueZ and I've verified it. 

BlueZ logs:

[DFU_Test:/service000c/char000d]# write 01 04
Attempting to write /org/bluez/hci0/dev_F1_6F_DE_EC_F1_D6/service000c/char000d
[CHG] Device F1:6F:DE:EC:F1:D6 Connected: no
Failed to write: org.bluez.Error.Failed


Web Bluetooth logs:

NotSupportedError: GATT operation failed for unknown reason.


I will apply the new "BlueZ-5.38" label to this bug so that we can ask ChromeOS people to update it when new release of BlueZ gets released. I'll mark it as "Verified" when it gets merged.
Labels: -BlueZ-5.38 Bluez-5.39
Blockedon: 600655

Comment 9 by ortuno@chromium.org, May 13 2016

Status: Fixed (was: Assigned)
Status: Verified (was: Fixed)
Bulk verified

Sign in to add a comment