Bug 1076898

Summary: Regression: bluetooth headset not connecting since last update, workaround included
Product: [openSUSE] openSUSE Tumbleweed Reporter: Vincent Petry <PVince81>
Component: BasesystemAssignee: Stefan Seyfried <seife>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: PVince81
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 1101119    
Attachments: Log with errors

Description Vincent Petry 2018-01-20 14:48:14 UTC
Before upgrading, connecting to bluetooth headset from TaoTronics worked correctly. I also have a cheap bluetooth watch and connecting to it with bluetoothctl worked fine.

Today I updated Tumbleweed to snapshot 20180117 and I observe the following behavior:

1) Connecting to bluetooth headset does not work any more even after a fresh boot. It connects shortly then disconnects. Both with the Plasma widget and with bluetoothctl.
2) Sometimes even after a fresh boot, the plasma widget doesn't show any of the known bluetooth devices
3) Strangely connecting to my bluetooth watch still works with bluetoothctl.

From what I remember, before the update I had bluez-5.47 and now it has been updated to 5.48.

Furthermore there is a similar report here for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1534857

The workaround, as indicated in that link, is to restart the bluetooth service with "systemctl restart bluetooth". After that the headset can connect again.

This is on a Dell XPS 13 9333 (different model than the above).

There are already logs in the Fedora ticket, I'll reboot now to try and gather some from here.

Please let me know if you need further information.
Comment 1 Vincent Petry 2018-01-20 14:53:29 UTC
Created attachment 756957 [details]
Log with errors

I've attached the log from journalctl from the connection failure.

Please note that during the short time where the connection to the headset is done, I can hear a beep in the headset which is an indication from its hardware that the connection was done. However the laptop / bluez somehow decides to disconnect again.
Comment 2 Vincent Petry 2018-01-20 15:06:15 UTC
Okay, so I forgot to mention something: I had the module "btusb" blacklisted by default. The reason was mostly to save some power when I don't use bluetooth. I wonder if those Fedora users did the same.

Anyway, now I removed "btusb" from blacklist and rebooted. And now it all works !

This seems to make sense because I suspect that whenever the bluetooth service is started at boot time, it needs btusb to be loaded already. So if you load the module afterwards, you need to restart the service.

At this point, if this is by design, feel free to close as the problem is solved for me.

-----------------------

My bluetooth adapter is built-in, so far so good.

But what happens for people who have bluetooth USB dongles ? Would btusb only load later once the dongle is plugged in ? If that's the case, then the problem I describe *might* happen for said users who might need to restart the bluetooth service.

Now this is marked as regression, it used to work with previous bluez versions. So not sure if this is something to be fixed upstream or whether this slight change of behavior / expectation is by design.
Comment 3 Stefan Seyfried 2018-01-24 13:56:16 UTC
well, blacklisting the driver for the hardware is of course not helping :-)

I think bluetoothd should still pick up devices that are added after starting (hot-plugged USB dongles come to my mind).

Anyway, this is not an openSUSE problem, so I'd kindly ask you to report the issue upstream to the bluez-devel mailinglist at linux-bluetooth@vger.kernel.org
Comment 4 Vincent Petry 2018-01-25 06:46:40 UTC
Thanks, makes sense.

I just observed that resuming from suspend also causes the issue and requires to restart the bluetooth service.

Thanks for mentioning the mailing list.

It was already reported by someone here on the mailing list: https://www.spinics.net/lists/linux-bluetooth/msg73824.html.

I've sent my own message there which should appear shortly in the archives.
Comment 5 Vincent Petry 2018-02-06 15:33:32 UTC
Email discussion and investigation in progress: https://marc.info/?l=linux-bluetooth&m=151792734112865&w=2

Breaking commit in bluez: d6e9539e31c6bb5afd39ec6f09c518d232e6345d
Comment 6 Stefan Seyfried 2018-02-11 21:22:13 UTC
I have added the patch from commit 1873096352f518d3247f8efb3c2e0aa8804e50ac to the bluez package in home:seife:testing

Could you please test if this fixes the issue for you? If yes, I'll submit this to Factory.
Comment 7 Vincent Petry 2018-02-11 22:13:34 UTC
I have tested it and posted here https://marc.info/?l=linux-bluetooth&m=151815774828197&w=2

If this is the same patch from that email then yes it worked for me!
Comment 8 Vincent Petry 2018-02-11 22:14:17 UTC
I'll test the package from your home also and report back.
Comment 9 Vincent Petry 2018-02-12 06:37:29 UTC
Tested with bluez package from home:seife:testing and I can confirm that:
- resuming after suspend can properly reconnects the headset
- loading btusb module after restarting bluetooth service works
Comment 10 Stefan Seyfried 2018-02-12 07:38:40 UTC
Thanks, package with patch is on its way to factory.
https://build.opensuse.org/request/show/575486

(And yes, testing the package is IMO important because a) I could have done something wrong integrating the patch and b) maybe it works against git master but not older released code :-)
Comment 11 Vincent Petry 2018-02-12 08:09:14 UTC
Of course, makes perfect sense :-)
Comment 12 Swamp Workflow Management 2018-02-12 09:00:07 UTC
This is an autogenerated message for OBS integration:
This bug (1076898) was mentioned in
https://build.opensuse.org/request/show/575499 Factory / bluez
Comment 13 Stefan Seyfried 2018-02-18 12:08:17 UTC
the fix has landed in Factory