Issue seen on 8743.25.0 Tidus device

Hello fukino@,

Can you help with taking a look at this issue? Thanks.

pbathini@, which version of Chromium are you using? The system menu UI in your screenshots is out of date; in version 56 and later the system menu should have a different material design appearance. The flag #ash-md in about:flags should be set to 'Default'.

Re #4 , this issue was raised a while back in sep 2016.we didn't have the new UI back then.

I can still see the issue on M-56 with the DR-BT-101 headphones.

Deleted: Screenshot 2017-01-19 at 12.17.35 PM.png 240 KB

	Screenshot 2017-01-19 at 12.17.35 PM.png 240 KB View Download

fukino@, friendly ping on this issue. Should this be punted to m-58? 57 is already past branch.

Punting to M58...

We see "Connecting..." in both chrome://settings (via chrome.bluetoothPrivate API) and system tray (directly calling BluetoothAdapter::GetDevices()).
I guess the adapter actually says the device is connecting.

ortuno@, could you help us triage this issue?

From Pramod's log, it looks like something happened on cras or bluez.  Let me take this issue.

When calling create_conn(), it incurs ext_io_disconnected() callback.
2016-09-12T14:47:22.818768-07:00 ERR bluetoothd[1083]: Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
2016-09-12T14:51:43.582886-07:00 ERR bluetoothd[1083]: Unable to get connect data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
2016-09-12T16:17:49.758681-07:00 ERR bluetoothd[1083]: Unable to get io data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107)
2016-09-12T16:18:03.251904-07:00 ERR bluetoothd[1083]: Unable to get Headset Voice gateway SDP record: Host is down
2016-09-12T16:18:42.072940-07:00 INFO bluetoothd[1083]: /org/bluez/hci0/dev_00_1F_82_29_1A_54/fd1: fd(30) ready

 Issue 542411  has been merged into this issue.

Hi guys,

there's a dup issue(https://issuetracker.google.com/35585050) and there're some debug logs might be helpful...

from those debug log, it looks like bluez haven't got connect request from the browser(only requests from cras), so there would not be any connect response to dismiss the dialog.

b/35587081 merged to this issue.

This is seen on 9557.0.0 build on mickey device also

Deleted: Screenshot 2017-05-16 at 11.41.03 AM.png 991 KB

	Screenshot 2017-05-16 at 11.41.03 AM.png 991 KB View Download

Hi #16,

could you try attached bluez(untar it to the root dir of the dut, then reboot)?

if it still repro with that, please upload logs

Deleted: bluez.tgz 4.7 MB

bluez.tgz 4.7 MB Download

hmm, i got a DR-BT101, which can repro this issue.

so it looks like cras somehow try to connect a2dp during browser's pair request, then break the pair request's reply(by calling device_browse_sdp during pairing). so the browser would not continue to trigger connect, so it could not dismiss that dialog which supposed to be done after connect finished.



cras                             browser

                                 try to pair
                                   call device_bonding_complete
try to connect to a2dp
  call device_browse_sdp
                                     call device_browse_sdp
                                       return -EBUSY
  call device_svc_resolved             <---no reply to browser
    call browse_request_complete
      send reply to cras



so ether we fix the bluez, to add the missing reply for EBUSY(in device_browse_sdp?)
or modify the browser to listen paired notify instead of waiting for paired reply.

Deleted: bluetooth.log 64.1 KB

bluetooth.log 64.1 KB View Download

attaching my hacky patch for "add missing reply in bluez".

please CC vapier@chromium.org for it (i always ask mike for help when i found something wrong in upstream tools...)

and please also CC cras guys(hychao@chromium.org) to check why it act different for DR-BT101(maybe this is not a problem)

Deleted: bluez.diff 947 bytes

bluez.diff 947 bytes Download

so, the question is would bluez guarantee to reply pair request whether success or not?

if so, it should be a bluez issue, maybe we should double check the bluez pair flow, since this might not be need only case it would not reply pair request.

if not, i think we should let chrome browser not to rely on it(the reply), but listen to the paired notify to trigger next step(connect request)

and maybe we should even check the connect flow too, since we are currently rely on the connect reply too, maybe that is risky too.

hmm, i saw bluez upstream fixes some issues like this:

76d1b42 core/gatt: Fix not replying if db operation fail
7bf8f04 core/device: Fix not replying to Pair
00d0e76 Fix not replying Acquire request when resume fails
d7887a4 core: Fix not replying to DisconnectProfile

so guess we should fix this issue(not replying to Pair) in bluez(upstream?)

and checking device_bonding_complete more carefully, there're some cases it would lose reply:


void device_bonding_complete(struct btd_device *device, uint8_t bdaddr_type,
                                                                uint8_t status)
{
...
        /* If we're already paired nothing more is needed */
        if (state->paired)
                return; <--- here
...
                if (bdaddr_type == BDADDR_BREDR)
                        device_browse_sdp(device, bonding->msg); <--- here
                else
                        device_browse_gatt(device, bonding->msg); <--- here
...
                        device->discov_timer = g_timeout_add_seconds(
                                                        DISCOVERY_TIMER,
                                                        start_discovery, <-- here(inside of start_discovery)
                                                        device);





and i saw Luiz(luiz.von.dentz@intel.com) tried to fix something simulate:
commit 7bf8f04605cef49c6851eea97d2a7c1f80910c66
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Jan 19 12:52:43 2015 +0200

    core/device: Fix not replying to Pair

    req->msg was not always set which cause no reply to be sent.


could you CC him for some help?

Issue 679921 has been merged into this issue.