Bluetooth headphones disconnect immediately after pairing

Bluetoothctl logs:

Hardware info:

System:
  Kernel: 6.15.8-arch1-1 arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.4.3 Distro: EndeavourOS
Machine:
  Type: Laptop System: LENOVO product: 81BG v: Lenovo ideapad 320-15IKB
    serial: <superuser required>
  Mobo: LENOVO model: LNVNB161216 v: SDK0J40709 WIN
    serial: <superuser required> UEFI: LENOVO v: 6JCN31WW date: 04/28/2019
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio driver: snd_hda_intel
  API: ALSA v: k6.15.8-arch1-1 status: kernel-api
  Server-1: PipeWire v: 1.4.7 status: active
Bluetooth:
  Device-1: Qualcomm Atheros driver: btusb type: USB
  Report: btmgmt ID: hci0 state: up address: N/A

Headphones are charged, work with other devices and have previously worked with this laptop. Unfortunately I don’t have any other devices I could try connecting to see if they also fail.
I am dual-booting with Windows 10.

Restarting bluetoothctl, unpairing and pairing, reloading the btusb module and rebooting the laptop don’t work.

Dual boot pairing

Maybe that’s helpful in any way. But I’m not exactly sure, if it is the cause of your described problem. It seems to go into the same direction.

inxi --network --bluetooth

Just to check which Qualcomm Atheros it actually is. As I’ve seen reports that the firmware had to be installed manually.

However that issue happens when the device gets paired on the other OS, I haven’t used bluetooth on windows at all so the keys can’t have been replaced. I will test it out when I have the time though, thanks!

It all worked before (1 month ago is the most recently I’ve used my headphones with my laptop) however I did do a massive update after leaving my laptop off for most of the month so something there may have broken it.

Update: I noticed it works after manually restarting bluetooth.service. I’ve tried digging into it and reading about similar issues to no avail - I suspect it was caused by the update of either bluez or some pipewire package.

For what it’s worth, chatgpt suggests the issue is caused by bluez being loaded before pipewire/wireplumber, not detecting them and never checking again. Thus when I connect, bluez accepts the connection initially but then notices it doesn’t have any backend to handle the headphones and disconnects.

I simply made a script run on startup that will restart bluetooth.service after all the appropriate services are running and hopefully that solves it forever.