Assigning to mcchou@. 

Received from the developer via email today: 

We have tested 63.0.3239.20 from Chrome OS dev channel.

The result is that now the data written to the device arrives in the correct order, but the disconnection problem is still happening.

To minimize friction between Chromebook and our device in terms of BLE communication, we think that we can work in a PoC using the same BLE low-level implementation used in Chromebook, as far as I know, that is BlueZ. The problem is that we have no experience working with BlueZ library and it has a very steep learning curve, so it can take us long time to get it working.

Do you think some experienced developer from Chromebook team could help us to speed up this PoC giving some support, sample code or documentation about BlueZ library and its usage to create BLE peripheral devices?

We really think this can help Chromebook team and our team to speed up the resolution of the problem and this way we can give your product team more valuable information with can help to troubleshoot the BLE problems they are addressing to help all developers that are reporting BLE problems on Chromebook devices.

If you think this could be possible it will be great, else, if you need more information (hardware specs, data logs...) please tell me and we try to collect and attach it to the bug report we opened.

Can someone please provide comms that I can share with the developer regarding how/when this bug will be addressed? This is a high profile partner in Spain and they are eagerly awaiting our response.

Thank you!

Hi,

I've enabled detailed log for bluetooth in Chromebook and tried the next steps:

1) Establish connection with peripheral device.
2) Subscribe to characteristic 0x1202 (type NOTIFY)
3) Write several times to characteristic 0x1201 (type WRITE NO-RESPONSE)


Steps 1 and 2 seems Ok. But in step 3, after writing, connection is always closed. There are 2 different, but related, behaviours:

- In case writes are 7 or less, all writes are performed and then connection is lost.

- In case writes count is greater than 7, connection is lost after 7th write finishes, so the rest of data is lost.


I guess this will not be very relevant, but the data written is of string type in form of text commands (like "FWD", "BCK", "STOP"...)


I've attached a zip file containing logged data during the test.


P.S.: This has been tested on Acer Chromebook R11 and Samsung Chromebook Plus devices in developer mode and running 63.0.3239.20 from dev channel and the result was the same.

Deleted: chromebook-ble-issue-2017-11-01.zip 12.1 KB

chromebook-ble-issue-2017-11-01.zip 12.1 KB Download

The disconnection problem was incurred by the incorrect write response packet, i.e., an extra trailing 0, on the device side, not on the chromebook side. If you remove the trailing 0 in the write response packet sent by the device, that should fix the problem. 

Even if your app works well on an android device, that does not necessarily mean that the app does the correct thing. The bluetooth stack, bluez, in chromebook does check the packet format in a strict manner.


----- More details below -----

From the chrome-hcidump log in Comment#0.

# Packet A
# This was a correct Write Response. Note that dlen was 5 here which was correct.
> ACL Data RX: Handle 128 flags 0x02 dlen 5   [hci0] 11736.995578
    ATT: Write Response (0x13) len 0

# Packet B
# This was an incorrect Write Response. Note that dlen was 6 here which was incorrect.
# Hence, the error message, “invalid size", was shown.
> ACL Data RX: Handle 128 flags 0x02 dlen 6   [hci0] 11748.094864
    ATT: Write Response (0x13) len 1
    invalid size
    00


# If you check the device-hcidump log, you would find that the dlen was 6 corresponding to Packet B above. # A correct value should be 5.
1970-01-01 00:00:59.816964 < ACL data: handle 16 flags 0x00 dlen 6
    ATT: Write resp (0x13)

This invalid ATT packet was discarded at l2cap layer and was not passed up to higher layer; hence it led to a timeout in kernel after 2 seconds. The timeout caused the disconnection.

So please check if you accidentally append “0” in the write response packet on the device side. And please let us know if this fixes the issue.

Per C#9, this issue was caused on the peripheral side instead of on the chrome os side. 

abelcsz@gmail.com please let me know if you have a different view point. I will close this issue if there is no response within 1 week. Thanks!

Per C#9, this issue was caused on the peripheral side instead of on the chrome os side. Hence, I will mark it WontFix.