Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1596950 - when closing bluetooth panel, connection is lost
Summary: when closing bluetooth panel, connection is lost
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Don Zickus
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-06-30 16:47 UTC by Chris Murphy
Modified: 2018-07-26 15:32 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)
full journal (deleted)
2018-06-30 16:50 UTC, Chris Murphy
no flags Details
journal partial (deleted)
2018-06-30 16:51 UTC, Chris Murphy
no flags Details
hcidump -t (deleted)
2018-06-30 16:51 UTC, Chris Murphy
no flags Details
bluetooth mouse disconnect (deleted)
2018-07-03 19:30 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2018-06-30 16:47:44 UTC
Description of problem:

If I'm using any bluetooth device (mouse or phone), and Gnome Control Center is set on the Bluetooth panel, and then I close that Bluetooth panel either by switching to another panel or closing GCC - the bluetooth connection to the device is interrupted: mouse stops working, file send fails. (It later recovers, but...)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Pair with cell phone, leave GCC-Bluetooth panel open
2. Start sending files
3. Close GCC-Bluetooth panel (upper right X)

Actual results:

File sending immediately stops, all unsent files fail.

Expected results:

File sending should continue.

Additional info:

In the attached logs (hcidump and journal with bluetoothd -d enabled), files are successfully sending (GCC-bluetooth panel open) at  Jun 30 10:25:30.

At Jun 30 10:27:07 I close the panel.
At Jun 30 10:27:11 file send is failing.

Comment 1 Chris Murphy 2018-06-30 16:50:30 UTC
Created attachment 1455679 [details]
full journal

'journalctl -b' which spans over a days

Comment 2 Chris Murphy 2018-06-30 16:51:12 UTC
Created attachment 1455680 [details]
journal partial

'journalctl -b' but the top is cut off to start with the approximate time of this bug

Comment 3 Chris Murphy 2018-06-30 16:51:59 UTC
Created attachment 1455681 [details]
hcidump -t

times match up with the previous journals

Comment 4 Chris Murphy 2018-06-30 17:17:33 UTC
See also bug 1596951 which might be a duplicate. That bug starts out with nothing going on, trying to send a file, and the send fails. Whereas this bug starts out with files successfully sending, closing GCC-bt panel, and sends failing.

The thing in common is that send fails if GCC-bt panel isn't open.

Comment 5 Chris Murphy 2018-06-30 17:45:05 UTC
Yeah so I think this is a dup of bug 1596951 even though the manifestations are slightly different. Ultimately if Bluetooth settings panel is not open, I cannot send files from phone to Fedora laptop. If it is open, I can send. 100% reproducible.

Comment 6 Bastien Nocera 2018-07-02 09:05:05 UTC
Receiving files will only work while the panel is opened, that's as designed, implemented and documented:

If the documentation is unclear, please file an issue at:

As for the mouse disconnecting, I don't know what the problem is, but the Bluetooth panel should have no effect on the mouse's connection, and is likely a bug in bluez.

Let me reassign to it, but you'll need to provide bluetoothd debug logs (run "bluetoothd -n -d" as root after having shut down the running one), so we can see what disconnects the mouse.

Comment 7 Chris Murphy 2018-07-03 19:30:08 UTC
Created attachment 1456322 [details]
bluetooth mouse disconnect

In this journal snippet, the mouse stopped working at about Jul 03 13:16:55.

The {gnome-shell[1637]: Object Meta.WindowActor} entry in the log I think is the bluetooth icon disappearing. None of the bluetoothd disconnect times match up with the actual loss of function, but closer to recovery.

Debugging bluetooth stuff has been extraordinarily difficult because the problems are constant, non-deterministic, and not reproducible on command. Sometimes the mouse vanishes every 5 minutes. Sometimes not for an hour. I also get a different set of behaviors with a fresh boot versus wake from suspend to RAM, in that case often the GUI says it's connected to the mouse, but the mouse isn't working; or othertimes GUI says it's not connected, and refuses to connect. Rebooting fixes it. For all I know there are 1/2 dozen bugs racing against each other.

Note You need to log in before you can comment on or make changes to this bug.