Hello!
I have a problem connecting Sennheiser Momentum True Wireless 2
headphones over Bluetooth. The headphones say "Connected" and then
reboot immediately after. After reboot the headphones say "Power on" and
try connecting again, and fail the same way, and so on.
From the Bluetooth packet dump it looks like the problem happens after
bluetoothd sends AVRCP ListPlayerApplicationSettingAttributes message to
the headphones. The headphones send Not Implemented response and then
reboot. Both in the request and the response Wireshark shows warnings
about encoding issues.
I'm attaching a packet dump captured from one of the connection
attempts. The ListPlayerApplicationSettingAttributes message is in
packet 262 and the response is in packet 264.
This is on Kubuntu 20.04. I tried bluez 5.53 from Kubuntu and revision
3146b7a0785758be2d4e894d44e99d29c0db983e from git master - the behavior
is the same.
I've also verified that the headphones do work on Windows 10. On that
system, ListPlayerApplicationSettingAttributes is not present in the
packet exchange. I can provide the packet dump from Windows, if needed.
I hope this is the right place to report problems like this one. If not
- sorry, and please point me to the right place.
Thank you.
On 2020-05-06 19:56, Andrey Semashev wrote:
> Hello!
>
> I have a problem connecting Sennheiser Momentum True Wireless 2
> headphones over Bluetooth. The headphones say "Connected" and then
> reboot immediately after. After reboot the headphones say "Power on" and
> try connecting again, and fail the same way, and so on.
>
> From the Bluetooth packet dump it looks like the problem happens after
> bluetoothd sends AVRCP ListPlayerApplicationSettingAttributes message to
> the headphones. The headphones send Not Implemented response and then
> reboot. Both in the request and the response Wireshark shows warnings
> about encoding issues.
>
> I'm attaching a packet dump captured from one of the connection
> attempts. The ListPlayerApplicationSettingAttributes message is in
> packet 262 and the response is in packet 264.
>
> This is on Kubuntu 20.04. I tried bluez 5.53 from Kubuntu and revision
> 3146b7a0785758be2d4e894d44e99d29c0db983e from git master - the behavior
> is the same.
>
> I've also verified that the headphones do work on Windows 10. On that
> system, ListPlayerApplicationSettingAttributes is not present in the
> packet exchange. I can provide the packet dump from Windows, if needed.
>
> I hope this is the right place to report problems like this one. If not
> - sorry, and please point me to the right place.
>
> Thank you.
I'll add that I can connect the headphones if I disable AVRCP by adding
--noplugin=avrcp to bluetoothd command line.
Hi Andrey,
On Wed, May 6, 2020 at 10:32 AM Andrey Semashev
<[email protected]> wrote:
>
> On 2020-05-06 19:56, Andrey Semashev wrote:
> > Hello!
> >
> > I have a problem connecting Sennheiser Momentum True Wireless 2
> > headphones over Bluetooth. The headphones say "Connected" and then
> > reboot immediately after. After reboot the headphones say "Power on" and
> > try connecting again, and fail the same way, and so on.
> >
> > From the Bluetooth packet dump it looks like the problem happens after
> > bluetoothd sends AVRCP ListPlayerApplicationSettingAttributes message to
> > the headphones. The headphones send Not Implemented response and then
> > reboot. Both in the request and the response Wireshark shows warnings
> > about encoding issues.
> >
> > I'm attaching a packet dump captured from one of the connection
> > attempts. The ListPlayerApplicationSettingAttributes message is in
> > packet 262 and the response is in packet 264.
> >
> > This is on Kubuntu 20.04. I tried bluez 5.53 from Kubuntu and revision
> > 3146b7a0785758be2d4e894d44e99d29c0db983e from git master - the behavior
> > is the same.
> >
> > I've also verified that the headphones do work on Windows 10. On that
> > system, ListPlayerApplicationSettingAttributes is not present in the
> > packet exchange. I can provide the packet dump from Windows, if needed.
> >
> > I hope this is the right place to report problems like this one. If not
> > - sorry, and please point me to the right place.
> >
> > Thank you.
>
> I'll add that I can connect the headphones if I disable AVRCP by adding
> --noplugin=avrcp to bluetoothd command line.
Weird the ListPlayerApplicationSettingAttributes should only really be
used when the remote device claims to be have target role but I doubt
the headsets would be implementing that so perhaps we are not
detecting this properly, do you have the HCI traces in btsnoop format?
You can collect that with use of btmon.
--
Luiz Augusto von Dentz
Hi Andrey,
On Thu, May 7, 2020 at 1:29 PM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi Andrey,
>
> On Wed, May 6, 2020 at 10:32 AM Andrey Semashev
> <[email protected]> wrote:
> >
> > On 2020-05-06 19:56, Andrey Semashev wrote:
> > > Hello!
> > >
> > > I have a problem connecting Sennheiser Momentum True Wireless 2
> > > headphones over Bluetooth. The headphones say "Connected" and then
> > > reboot immediately after. After reboot the headphones say "Power on" and
> > > try connecting again, and fail the same way, and so on.
> > >
> > > From the Bluetooth packet dump it looks like the problem happens after
> > > bluetoothd sends AVRCP ListPlayerApplicationSettingAttributes message to
> > > the headphones. The headphones send Not Implemented response and then
> > > reboot. Both in the request and the response Wireshark shows warnings
> > > about encoding issues.
> > >
> > > I'm attaching a packet dump captured from one of the connection
> > > attempts. The ListPlayerApplicationSettingAttributes message is in
> > > packet 262 and the response is in packet 264.
> > >
> > > This is on Kubuntu 20.04. I tried bluez 5.53 from Kubuntu and revision
> > > 3146b7a0785758be2d4e894d44e99d29c0db983e from git master - the behavior
> > > is the same.
> > >
> > > I've also verified that the headphones do work on Windows 10. On that
> > > system, ListPlayerApplicationSettingAttributes is not present in the
> > > packet exchange. I can provide the packet dump from Windows, if needed.
> > >
> > > I hope this is the right place to report problems like this one. If not
> > > - sorry, and please point me to the right place.
> > >
> > > Thank you.
> >
> > I'll add that I can connect the headphones if I disable AVRCP by adding
> > --noplugin=avrcp to bluetoothd command line.
>
> Weird the ListPlayerApplicationSettingAttributes should only really be
> used when the remote device claims to be have target role but I doubt
> the headsets would be implementing that so perhaps we are not
> detecting this properly, do you have the HCI traces in btsnoop format?
> You can collect that with use of btmon.
Looks like the device is setting the bit for Category 1:
Player/Recorder which is why we are sending player related command,
other stacks might not do that because they are not dual-role, cannot
act as controllers, even if Player Application Settings is optional
for category 1 it still means that we could perhaps list them. It
looks like we are not parsing properly the ctype since it appears that
it returns AVC_CTYPE_NOT_IMPLEMENTED instead of AVC_CTYPE_REJECTED, is
that perhaps causing a crash on bluetoothd?
>
> --
> Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
On Thu, May 7, 2020 at 11:58 PM Luiz Augusto von Dentz
<[email protected]> wrote:
>
> Hi Andrey,
>
> On Thu, May 7, 2020 at 1:29 PM Luiz Augusto von Dentz
> <[email protected]> wrote:
> >
> > Hi Andrey,
> >
> > On Wed, May 6, 2020 at 10:32 AM Andrey Semashev
> > <[email protected]> wrote:
> > >
> > > On 2020-05-06 19:56, Andrey Semashev wrote:
> > > > Hello!
> > > >
> > > > I have a problem connecting Sennheiser Momentum True Wireless 2
> > > > headphones over Bluetooth. The headphones say "Connected" and then
> > > > reboot immediately after. After reboot the headphones say "Power on" and
> > > > try connecting again, and fail the same way, and so on.
> > > >
> > > > From the Bluetooth packet dump it looks like the problem happens after
> > > > bluetoothd sends AVRCP ListPlayerApplicationSettingAttributes message to
> > > > the headphones. The headphones send Not Implemented response and then
> > > > reboot. Both in the request and the response Wireshark shows warnings
> > > > about encoding issues.
> > > >
> > > > I'm attaching a packet dump captured from one of the connection
> > > > attempts. The ListPlayerApplicationSettingAttributes message is in
> > > > packet 262 and the response is in packet 264.
> > > >
> > > > This is on Kubuntu 20.04. I tried bluez 5.53 from Kubuntu and revision
> > > > 3146b7a0785758be2d4e894d44e99d29c0db983e from git master - the behavior
> > > > is the same.
> > > >
> > > > I've also verified that the headphones do work on Windows 10. On that
> > > > system, ListPlayerApplicationSettingAttributes is not present in the
> > > > packet exchange. I can provide the packet dump from Windows, if needed.
> > > >
> > > > I hope this is the right place to report problems like this one. If not
> > > > - sorry, and please point me to the right place.
> > > >
> > > > Thank you.
> > >
> > > I'll add that I can connect the headphones if I disable AVRCP by adding
> > > --noplugin=avrcp to bluetoothd command line.
> >
> > Weird the ListPlayerApplicationSettingAttributes should only really be
> > used when the remote device claims to be have target role but I doubt
> > the headsets would be implementing that so perhaps we are not
> > detecting this properly, do you have the HCI traces in btsnoop format?
> > You can collect that with use of btmon.
>
> Looks like the device is setting the bit for Category 1:
> Player/Recorder which is why we are sending player related command,
> other stacks might not do that because they are not dual-role, cannot
> act as controllers, even if Player Application Settings is optional
> for category 1 it still means that we could perhaps list them. It
> looks like we are not parsing properly the ctype since it appears that
> it returns AVC_CTYPE_NOT_IMPLEMENTED instead of AVC_CTYPE_REJECTED, is
> that perhaps causing a crash on bluetoothd?
It's not the bluetoothd what crashes, it's the headset. My
understanding is that the headset doesn't support
ListPlayerApplicationSettingAttributes and does a poor job of handling
it. So after sending the (malformed) AVC_CTYPE_NOT_IMPLEMENTED
response it reboots.
If bluetoothd doesn't expect AVC_CTYPE_NOT_IMPLEMENTED, I suppose, it
should be updated to handle it. But I don't think it is going to fix
the problem of the headset rebooting. I think the fix should be to
somehow avoid sending ListPlayerApplicationSettingAttributes. Or maybe
encode it differently (e.g. by adding some parameters, if there are
any required by the spec.) Also, since I never got beyond
ListPlayerApplicationSettingAttributes, there may be more issues down
the road. I'm willing to test any patches.
Also, I filed a support request to Sennheiser regarding this issue. No
reply so far, and I don't have much hope for them solving it, but
still.
On 2020-05-07 23:29, Luiz Augusto von Dentz wrote:
> Hi Andrey,
>
> On Wed, May 6, 2020 at 10:32 AM Andrey Semashev
> <[email protected]> wrote:
>>
>> On 2020-05-06 19:56, Andrey Semashev wrote:
>>> Hello!
>>>
>>> I have a problem connecting Sennheiser Momentum True Wireless 2
>>> headphones over Bluetooth. The headphones say "Connected" and then
>>> reboot immediately after. After reboot the headphones say "Power on" and
>>> try connecting again, and fail the same way, and so on.
>>>
>>> From the Bluetooth packet dump it looks like the problem happens after
>>> bluetoothd sends AVRCP ListPlayerApplicationSettingAttributes message to
>>> the headphones. The headphones send Not Implemented response and then
>>> reboot. Both in the request and the response Wireshark shows warnings
>>> about encoding issues.
>>>
>>> I'm attaching a packet dump captured from one of the connection
>>> attempts. The ListPlayerApplicationSettingAttributes message is in
>>> packet 262 and the response is in packet 264.
>>>
>>> This is on Kubuntu 20.04. I tried bluez 5.53 from Kubuntu and revision
>>> 3146b7a0785758be2d4e894d44e99d29c0db983e from git master - the behavior
>>> is the same.
>>>
>>> I've also verified that the headphones do work on Windows 10. On that
>>> system, ListPlayerApplicationSettingAttributes is not present in the
>>> packet exchange. I can provide the packet dump from Windows, if needed.
>>>
>>> I hope this is the right place to report problems like this one. If not
>>> - sorry, and please point me to the right place.
>>>
>>> Thank you.
>>
>> I'll add that I can connect the headphones if I disable AVRCP by adding
>> --noplugin=avrcp to bluetoothd command line.
>
> Weird the ListPlayerApplicationSettingAttributes should only really be
> used when the remote device claims to be have target role but I doubt
> the headsets would be implementing that so perhaps we are not
> detecting this properly, do you have the HCI traces in btsnoop format?
> You can collect that with use of btmon.
Here is the btsnoop dump attached. It was taken with your patch
regarding AVC_CTYPE_NOT_IMPLEMENTED applied.