On Thu, May 7, 2020 at 11:58 PM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi Andrey, > > On Thu, May 7, 2020 at 1:29 PM Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: > > > > Hi Andrey, > > > > On Wed, May 6, 2020 at 10:32 AM Andrey Semashev > > <andrey.semashev@xxxxxxxxx> 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.
