New issue
Advanced search Search tips

Issue 904114 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 6
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Write to and then read from the same characteristic fails

Reported by j...@zode64.com, Nov 10

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Steps to reproduce the problem:
Using a PocketLab Voyager or PocketLab Weather device.

We use Read and Write on a characteristic to get calibration data for
a sensor. For example, for our temperature, pressure, humidity sensor,
we will write "0x02" to the characteristic, then read the
characteristic for temperature calibration data.

Using chrome://bluetooth-internals on Mac this sequence works and is the expected behavior
- Write "0x02" to characteristic
- Message pops up "Write Succeeded"
- Read same characteristic
- Message pops up "Read Succeeded"
- Data 0x000... read into the Value field

Using chrome://bluetooth-internals on Win10, Chrome 70.0.3538.77, this
sequence returns no calibration data
- Write "0x02" to characteristic
- Message pops up "Write Succeeded"
- Read same characteristic
- Message pops up "Read Succeeded"
- No data is read into the Value field

What is the expected behavior?
Data is read from the value field

What went wrong?
No data is read from the value field

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 70.0.3538.77  Channel: stable
OS Version: 10
Flash Version:
 
Labels: Needs-Triage-M70
Labels: Triaged-ET TE-Hardware-Dependency
The issue needs to be tested using a PocketLab Voyager or PocketLab Weather device. As ET-team doesn't have the above devices to test the issue. Hence, adding label TE-Hardware-Dependency.

Thanks...!!
My understanding is that the chrome team in California does have one of these devices. Not sure where the ET team fits into this.
Owner: reillyg@chromium.org
Status: Assigned (was: Unconfirmed)
My team in MTV has one of these devices and will investigate after I finish with  issue 902241 .
Labels: Needs-Feedback
I am trying to reproduce this issue but I don't know which characteristic you are trying to write to. The device I have reports that it is Rev 1.1.0.
Apologies, the characteristic is F000AA16-0452-4000-B000-000000000000
Labels: -Needs-Feedback
Status: Started (was: Assigned)
It looks like the issue is that we are calling ReadValueAsync() which returns a cached value. Testing a change to call ReadValueWithCacheModeAsync(Uncached) instead.
Project Member

Comment 8 by bugdroid1@chromium.org, Dec 6

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

commit d810f68079066a4a8f9e9a3c3730fc1bcdf72f7a
Author: Reilly Grant <reillyg@chromium.org>
Date: Thu Dec 06 19:07:29 2018

[bluetooth][win] Force uncached characteristic value reads

The ReadValueAsync() method will return the characteristic value
cached by Windows. It appears that when a value is written to a
characteristic Windows assumes that the device will respond with the
value written and will update its cache to that value. This is a
problem for devices which do not follow this behavior and instead
respond with an unrelated value.

This change switches to using the ReadValueWithCacheModeAsync() method
and passes the BluetoothCacheMode_Uncached flag in order to force
Windows to always read the value directly from the device.

Bug:  904114 
Change-Id: I76b214abd0004fc311e1f32a9457273df60a6f54
Reviewed-on: https://chromium-review.googlesource.com/c/1364393
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614437}
[modify] https://crrev.com/d810f68079066a4a8f9e9a3c3730fc1bcdf72f7a/device/bluetooth/bluetooth_remote_gatt_characteristic_winrt.cc
[modify] https://crrev.com/d810f68079066a4a8f9e9a3c3730fc1bcdf72f7a/device/bluetooth/test/fake_gatt_characteristic_winrt.cc

Status: Fixed (was: Started)
Please verify this in the next Canary update.
Project Member

Comment 10 by bugdroid1@chromium.org, Dec 7

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

commit dc08cacbde1ee26cbe43bbf576097dd9528467f2
Author: Reilly Grant <reillyg@chromium.org>
Date: Fri Dec 07 01:11:01 2018

[bluetooth][win] Force uncached descriptor value reads

This is a follow-up to r614437 which updates ReadRemoteDescriptor() to also use
the uncached variant of the ReadValueAsync() function so as not to return a
stale value.

Bug:  904114 
Change-Id: Ifb7e0be25f799eadc4f1e65aea6c6c5850649019
Reviewed-on: https://chromium-review.googlesource.com/c/1366321
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Commit-Queue: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614529}
[modify] https://crrev.com/dc08cacbde1ee26cbe43bbf576097dd9528467f2/device/bluetooth/bluetooth_remote_gatt_descriptor_winrt.cc
[modify] https://crrev.com/dc08cacbde1ee26cbe43bbf576097dd9528467f2/device/bluetooth/test/fake_gatt_descriptor_winrt.cc

Cc: santhoshkumar@chromium.org
 Issue 919314  has been merged into this issue.

Sign in to add a comment