New issue
Advanced search Search tips
Starred by 3 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
link

Issue 904114: 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

Comment 2 by krajshree@chromium.org, Nov 12

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...!!

Comment 3 by j...@zode64.com, Nov 12

My understanding is that the chrome team in California does have one of these devices. Not sure where the ET team fits into this.

Comment 4 by reillyg@chromium.org, Nov 14

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 .

Comment 5 by reillyg@chromium.org, Nov 16

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.

Comment 6 by j...@zode64.com, Nov 19

Apologies, the characteristic is F000AA16-0452-4000-B000-000000000000

Comment 7 by reillyg@google.com, Dec 6

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.

Comment 8 by bugdroid1@chromium.org, Dec 6

Project Member
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

Comment 9 by reillyg@chromium.org, Dec 6

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

Comment 10 by bugdroid1@chromium.org, Dec 7

Project Member
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

Comment 11 by reillyg@chromium.org, Jan 9

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

Comment 12 by ortuno@chromium.org, Feb 18 (5 days ago)

 Issue 933032  has been merged into this issue.

Sign in to add a comment