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): gnome-bluetooth-3.28.0-1.fc28.x86_64 gnome-bluetooth-libs-3.28.0-1.fc28.x86_64 bluejeans-1.35.15-1.x86_64 NetworkManager-bluetooth-1.10.10-1.fc28.x86_64 pulseaudio-module-bluetooth-12.0-1.fc28.x86_64 bluez-libs-5.50-1.fc28.x86_64 bluez-5.50-1.fc28.x86_64 bluez-obexd-5.50-1.fc28.x86_64 How reproducible: 100% 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.
Created attachment 1455679 [details] full journal 'journalctl -b' which spans over a days
Created attachment 1455680 [details] journal partial 'journalctl -b' but the top is cut off to start with the approximate time of this bug
Created attachment 1455681 [details] hcidump -t times match up with the previous journals
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.
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.
Receiving files will only work while the panel is opened, that's as designed, implemented and documented: https://help.gnome.org/users/gnome-help/stable/sharing-bluetooth.html.en If the documentation is unclear, please file an issue at: https://gitlab.gnome.org/GNOME/gnome-user-docs 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.
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.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.