Re: Apparent bluez 5.48 regression: Headphones fail to reconnect after suspend/resume

[Nathaniel McCallum <npmccallum@redhat.com>]

I'm seeing this too. My headphones go through a connect/disconnect
cycle a few times and then quit. Unpairing and repairing does make it
work.

On Tue, Jan 30, 2018 at 1:47 AM, Vincent Petry <pvince81@googlemail.com> wrote:
> Hello,
>
> On 01/25/2018 07:43 PM, Luiz Augusto von Dentz wrote:
>> Hi Vincent,
>>
>> On Thu, Jan 25, 2018 at 4:44 AM, Vincent Petry <pvince81@googlemail.com> wrote:
>>> Hello,
>>>
>>> I just joined the mailing list so can't directly reply to old messages,
>>> so sending with same title.
>>>
>>> I'm experiencing the same issue as Robert here
>>> https://www.spinics.net/lists/linux-bluetooth/msg73824.html, happening
>>> on the same laptop Dell XPS 13 but with different sub-model 9333, but on
>>> openSUSE Tumbleweed.
>>>
>>> It looks like the bluez component is in a wrong state when either
>>> loading btusb with modprobe later on or resuming from suspend. The
>>> workaround is to restart the systemd bluetooth daemon. I suspect that
>>> plugging in USB bluetooth dongles would also have the same issue but I
>>> don't have one to test.
>> Does the system have any controller after resume? Does bluetoothctl
>> report any device at all?
> After resume from suspend, bluetoothctl sees the controller, yes and it
> does report my usual three devices from the saved list.
>
> When I tell it to connect to the headset (which is turned on), I can
> hear the headset beep shortly which is the signal for connection, but
> then it disconnects again:
> Attempting to connect to E3:XX:XX:XX:XX:XX
> [CHG] Device E3:XX:XX:XX:XX:XX Connected: yes
> Failed to connect: org.bluez.Error.Failed
> [CHG] Device E3:XX:XX:XX:XX:XX Connected: no
>
> If I tell it to connect to my bluetooth watch it stays connected.
>
> Now I wanted to try accessing characteristics but the command
> "select-attribute" has gone missing ? I also tried "help gatt" as it
> seems to be a submenu but it says "Too many argumnets". Possibly another
> bug in bluez ? (I can send a separate email for this one if you want)
>
> Anyway, I have a Python script that uses Dbus and said Python script is
> able to connect to my watch and talk to it even in this state.
>
> So the bluez 5.48 regression seems to be specifically with headsets and
> also with scanning/discovering. I don't have any other device types to
> test with.
>
> The workaround is to restart the bluetooth service and enable bluetooth
> afterwards.
>
> Please make sure to look at
> https://bugzilla.suse.com/show_bug.cgi?id=1076898 for logs I posted.
>
> If you guys cannot reproduce the first regression I could try and bisect
> bluez locally to find the breaking change. For this I need to know how
> to set up bluez on my system after compiling. Is there any guide about
> this ? Should I tell it to overwrite the existing libs and reboot or is
> restarting the bluetooth service sufficient to make it use the newly
> installed version ?
>
> Thanks,
>
> Vincent
>
>>> It used to work correctly before the upgrade from 5.47 to 5.48.
>>>
>>> See my original report here for details:
>>> https://bugzilla.suse.com/show_bug.cgi?id=1076898
>>> Robert's report https://bugzilla.redhat.com/show_bug.cgi?id=1534857,
>>> also confirmed by a third person.
>>>
>>> Please let us know if this is reproducible on your side or whether it's
>>> an isolated case specific to our Dell hardware.
>>>
>>> Thanks,
>>>
>>> Vincent Petry
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html