Sony WF-1000XM6 call audio fails on Linux: first eSCO setup gets 0x1f, then ACL timeout

[Arka Bhuiyan <arkabhuiyancsedu@gmail.com>]

Hi,

My Sony WF-1000XM6 does not carry call audio on Linux. I'm sending this 
to report the failure and the evidence I have. I don't know whether the 
bug is in PipeWire, BlueZ, the kernel, or the device, so I'm asking here.

My setup

- HP Victus laptop and a personal workstation, both with Intel AX201 
(8087:0026).
- Kernel 7.3.1-1-cachyos (linux-cachyos 7.3.1-1), bluez 5.87-2.1, 
pipewire 1:1.6.8-1.2, wireplumber 0.5.15-1, linux-firmware 1:20261019-1. 
PipeWire and WirePlumber are pinned, so these are the versions running.
- Firmware loaded: intel/ibt-19-0-4.sfi, Firmware Version 83-7.26.
- Earbuds: Sony WF-1000XM6. I haven't checked its firmware version yet.
- I also have other Sony headsets and see the same failure with them. I 
haven't captured those yet.

What happens

When a call starts, the host sends an Enhanced Setup Synchronous 
Connection command. The controller accepts it (Command Status: Success), 
but no Synchronous Connect Complete follows. Later, an SCO Connect 
Complete arrives with Unspecified Error (0x1f) and handle 0xFFFF. About 
1 ms after that, the ACL link drops with Connection Timeout (0x08). In 
every failing capture I have, there is no codec exchange (+BCS or 
AT+BCS) between connect and that first setup.

How to reproduce

1. Pair and connect the WF-1000XM6.
2. Start a call in Teams for Linux, with nothing else changed.
3. Capture with sudo btmon.

Evidence (btmon times, in seconds)

- Cold run: setups at 26.02 and 50.12 are accepted with no completion. 
SCO Connect Complete with 0x1f at 46.345 and 62.114, each followed by 
ACL Disconnect with 0x08.
- Debug run: Enhanced Setup at 83.73 has no completion. SCO failure with 
0x1f at 104.078, then ACL 0x08 at 104.079. Another failure at 123.558. 
Before the first setup, the only HFP message is +CIEV: 2,1.
- Call capture: Enhanced Setup at 76.276, no completion. SCO 0x1f at 
96.628, ACL 0x08 at 96.629. The first codec exchange comes after the 
reconnect.

Workaround

If I force the codec exchange first, the setup succeeds. Before the 
call, I run two short capture streams: one on mSBC, then one on LC3-SWB. 
In the primed capture, +BCS: 2 and AT+BCS=2 come before the mSBC setup 
at 23.733, which succeeds at 24.19 (eSCO, Transparent). The LC3-SWB 
setup comes after +BCS: 3 and AT+BCS=3, and it also succeeds.

In a real call with the workaround, the mSBC setup at 43.23 succeeded at 
43.63, and the LC3-SWB setup at 52.22 succeeded at 53.28. Audio worked. 
There was a brief drop of about 1.2 seconds while the link switched.

What I ruled out or haven't checked

- Duplicate device records: there is only one record.
- Multipoint: it still fails with the phone's Bluetooth off.
- Wi-Fi coexistence: not tested properly.
- Firmware: not confirmed as the cause. I haven't compared it with the 
September update.
- CVE-2026-90255 and commit 0f00cd322d22: I haven't checked them against 
the 7.3.1-1 source.

Questions

1. Is it expected that a controller accepts Enhanced Setup Synchronous 
Connection and never completes it, with no earlier error?
2. Should the host time out sooner than the ACL supervision timeout?
3. Should the codec selection before the first setup come from the 
userspace implementation (PipeWire here) or from BlueZ?

I can send redacted btmon excerpts on request. I won't attach raw .snoop 
files or /var/lib/bluetooth info files, since they contain link keys.

-- 

Best Regards,
*Arka Bhuiyan*