New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 853137 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Bluetooth adapter is disabled on running magic tethering

Project Member Reported by josephsih@chromium.org, Jun 15 2018

Issue description

Chrome Version: eve-release/R67-10575.54.0

I also deployed a newer bluez package to the Eve up to this commit:
2018-05-22 15:55 Qiyu Hu CHROMIUM: Allow clients to specify a CCCD value in StartNotify()

What steps will reproduce the problem?
(1) Enable magic tethering. Login test user account.

What is the expected result?
The adapter should keep enabled.

What happens instead?
The adapter is disabled as soon as MT starts running. This occurs every time.

Sonny, could you help take a look since you have been working on the bluetooth power state for a while. Thanks!

The following logs showed that it was chrome that disabled the bluetooth adapter.

# The bluetooth_agent on chromium was :1.7
2018-06-15T16:57:30.223487+08:00 DEBUG bluetoothd[2343]: src/agent.c:add_default_agent() Default agent set to :1.7 /org/chromium/bluetooth_agent

# The adapter was enabled in the beginning.
2018-06-15T16:57:32.116766+08:00 INFO bluetoothd[2343]: adapter /org/bluez/hci0 has been enabled

# MT Test was started at this time.
Fri Jun 15 16:57:57 CST 2018

# In dbus log, it showed that :1.7 set Powered to false.
method call time=1529053087.032544 sender=:1.7 -> destination=org.bluez serial=388 path=/org/bluez/hci0; interface=org.freedesktop.DBus.Properties; member=Set
   string "org.bluez.Adapter1"
   string "Powered"
   variant       boolean false

# The adapter was disabled then.
2018-06-15T16:58:07.067348+08:00 INFO bluetoothd[2343]: adapter /org/bluez/hci0 has been disabled


 
0615_1657_mt_0x36_mdelay30_cycle50.tbz2
5.4 MB Download
This issue happens most of the time, but not always.
Hi Joseph,

This looks like a normal case of Bluetooth power initialization every time a user has just logged in.

user_chrome.log starts at 16:58:05.657295, this means that a user starts logging in at that time. And about 1.5 seconds later (16:58:07.030253) the preferences are loaded so Chrome applies the user's preference to Bluetooth power, which in this case is Off.

I'm wondering why magic tether starts at 16:57:57, even before a user logs in?
Hi Sonny, thanks for looking into the log!  I do not know why magic tethering started before a user logged in...

I tried to reproduce the issue today with the same setup. But I am not able to reproduce it any more. It is quite weird. 


The issue happened before this way. The adapter was on. I rebooted the machine (Eve), logged in, and started magic tethering. The adapter was disabled suddenly. In this case, isn't the adapter supposed to be on?

Let's close this issue for now? And maybe re-opened it when it occurs again. Thanks.
Status: WontFix (was: Untriaged)
Hi Joseph,

Okay, let's close this for now. And when that happens again feel free to reopen and attach the logs again for me to take a look. Thanks!

Sign in to add a comment