First, you should enter 6e400001-b5a3-f393-e0a9-e50e24dcca9e not 0x6e400001-b5a3-f393-e0a9-e50e24dcca9e.

It looks like you use BlueZ 5.36.
Chromium uses the new BlueZ property called "ServicesResolved" to resolve GATT services and this was introduced more recently. You may want to switch to BlueZ 5.39 instead: http://git.kernel.org/cgit/bluetooth/bluez.git/tag/?h=5.39.

Please use BlueZ 5.40 as current version of Chrome OS BlueZ fork (based on BlueZ 5.39) uses upstream patches from BlueZ 5.40: https://chromium.googlesource.com/chromiumos/third_party/bluez/+log/chromeos-5.39

Note that Chrome OS team is about to switch to BlueZ 5.40: https://bugs.chromium.org/p/chromium/issues/detail?id=617128

After updating to Bluez 5.40 I can get the device Characteristics, but only if the device is already listed in the cache (after executing "scan on" on bluetoothcrl).

Please find my logs attached for reference. I noted that btmon doesn't list any activity during this test.

Deleted: chrome_debug.log 4.1 KB

chrome_debug.log 4.1 KB View Download

Deleted: btmon.log 427 bytes

btmon.log 427 bytes View Download

What kernel are you using? Chrome does a filtered scan which is not supported on all kernels.

This is the btmon log after executing "scan on".

Deleted: btmon.log 7.3 KB

btmon.log 7.3 KB View Download

Oops sorry, just saw #1 i.e. kernel 4.6.0-1-amd64 which should work. From the logs it seems we stop the discovery session almost immediately, that's weird. I'll keep investigating.

Please find attached the bluetoothd.log

That was my test sequence:

1) run bluetoothd in debug mode
2) opened bluetoothctl and run "scan on"
3) opened chromium, loaded the device-info.html page
4) entered "Nordic" in the Device Name Prefix and clicked on "Get Bluetooth Device Info"

It returned:
Requesting Bluetooth Device...
> Name:             Nordic_UART
> Id:               67L/sG5miEkWH8tUGbfO0w==
> Allowed Services: 
> Connected:        false

There is not output in the btmon log because the device name was already in the cache

Deleted: bluetoothd.log 28.8 KB

bluetoothd.log 28.8 KB View Download

New logs

Deleted: bluetoothd.log 2.1 KB

bluetoothd.log 2.1 KB View Download

Deleted: chrome_debug.log 3.8 KB

chrome_debug.log 3.8 KB View Download

I'm not sure why but the adapter being added/removed may be the issue there:

[22379:22379:0628/172654:VERBOSE1:bluetooth_adapter_bluez.cc(970)] /org/bluez/hci0: adapter removed.

For info, here's how it looks on Chrome OS:

bluetoothd[1760]: src/adapter.c:set_discovery_filter() sender :1.11
bluetoothd[1760]: src/adapter.c:parse_discovery_filter_dict() filtered discovery params: transport: 7 rssi: 32767 pathloss: 32767
bluetoothd[1760]: src/adapter.c:set_discovery_filter() successfully pre-set filter
bluetoothd[1760]: src/adapter.c:start_discovery() sender :1.11
bluetoothd[1760]: src/adapter.c:update_discovery_filter() 
bluetoothd[1760]: src/adapter.c:discovery_filter_to_mgmt_cp() 
bluetoothd[1760]: src/adapter.c:trigger_start_discovery() 
bluetoothd[1760]: src/adapter.c:cancel_passive_scanning() 
bluetoothd[1760]: src/adapter.c:start_discovery_timeout() 
bluetoothd[1760]: src/adapter.c:start_discovery_timeout() adapter->current_discovery_filter == 1
bluetoothd[1760]: src/adapter.c:start_discovery_timeout() sending MGMT_OP_START_SERVICE_DISCOVERY 127, 7, 0
bluetoothd[1760]: src/adapter.c:start_discovery_complete() status 0x00
bluetoothd[1760]: src/adapter.c:discovering_callback() hci0 type 7 discovering 1 method 1
bluetoothd[1760]: src/adapter.c:stop_discovery() sender :1.11
bluetoothd[1760]: src/adapter.c:discovery_destroy() owner :1.11
bluetoothd[1760]: src/adapter.c:stop_discovery_complete() status 0x00
bluetoothd[1760]: src/adapter.c:trigger_passive_scanning() 
bluetoothd[1760]: src/adapter.c:discovering_callback() hci0 type 7 discovering 0 method 0

Luiz, may you have a look at this issue?

Alan, can you try setting ControllerMode = dual in /etc/bluetooth/main.conf to see if that changes anything. I believe we start dual scan from chrome. I wonder if that could be it.

After discussing offline with Alan, it turned out setting ControllerMode = dual in /etc/bluetooth/main.conf succeed. I've updated our Linux notes at https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/implementation-status.md#notes to include this check.

I'll follow up with BlueZ folks.

See http://article.gmane.org/gmane.linux.bluez.kernel/67926

The following patch should fix the problem:

http://article.gmane.org/gmane.linux.bluez.kernel/67934

Just applied http://article.gmane.org/gmane.linux.bluez.kernel/67934 locally and it works great on Chrome OS.
Alan, can you apply it as well on Chromium for Linux to confirm it also works on your side?

Testing to verify if error: "500 Internal Server Error" still happening.

I can confirm that setting ControllerMode = dual will works. Also I tested the patch and it fixed the issue.

http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=f9591e607948e80c65104d6eb980abeaa340fdab has been applied.
I'll update Chrome Implementation status notes once BlueZ 5.41 is released.

The patch mentioned in comment #18 is cherry-picked at https://chromium-review.googlesource.com/#/c/361161.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/5b88e58e74b5acd2b45b56cc7fe556806eafaf63

commit 5b88e58e74b5acd2b45b56cc7fe556806eafaf63
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Wed Jun 29 09:52:46 2016

UPSTREAM: core/adapter: Fix scan type for filtered discovery

The default type when using SetDiscoveryFilter shall be based on the
current adapter settings since the ControllerMode may set a different
mode or in case the adapter is single mode the code shall never assume
the adapter is SCAN_TYPE_DUAL by default.

BUG= chromium:623929 
TEST=emerge bluez

Change-Id: I86c6353559f4363225b5690f83b8f783aabceeac
Reviewed-on: https://chromium-review.googlesource.com/361161
Commit-Ready: François Beaufort <fbeaufort@chromium.org>
Commit-Ready: Miao-chen Chou <mcchou@chromium.org>
Tested-by: Miao-chen Chou <mcchou@chromium.org>
Reviewed-by: François Beaufort <fbeaufort@chromium.org>
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>

[modify] https://crrev.com/5b88e58e74b5acd2b45b56cc7fe556806eafaf63/src/adapter.c