Sony INZONE Buds (LE Audio only) terminate link with 0x13 before CIS setup; works on Windows 11, same controller

Sony INZONE Buds (LE Audio only) terminate link with 0x13 before CIS setup; works on Windows 11, same controller

[ultron321]

Hi,
 
I am unable to use a pair of LE-Audio-only earbuds (Sony INZONE Buds) over
Bluetooth on Linux. They bond and complete GATT discovery, but the peripheral
then terminates the ACL with reason 0x13 (Remote User Terminated) before any
CIS is set up, so no audio stream is ever established.
 
The same earbuds work out of the box on Windows 11 on the *same laptop / same
controller*, which rules out the controller and the earbud firmware and points
to the host stack.
 
 
Environment
-----------
- BlueZ:        5.86  (also reproduced with bluez-git master)
- Kernel:       7.1.2-arch3-1  (Arch / EndeavourOS)
- PipeWire:     1.6.7
- WirePlumber:  0.5.15
- liblc3:       installed
- bluetoothd:   running with Experimental enabled; BAP endpoints are registered:
      bluetoothd: Endpoint registered: path=/MediaEndpointLE/BAPSink/lc3
      bluetoothd: Endpoint registered: path=/MediaEndpointLE/BAPSource/lc3
 
 
Controller (btmgmt info)
------------------------
hci0  Primary controller  addr XX:XX:XX:XX:XX:XX  version 13  manufacturer 2 (Intel)
  supported settings: ... le secure-conn wide-band-speech cis-central cis-peripheral
                      ll-privacy past-sender past-receiver ...
  current settings:   powered bondable ssp br/edr le secure-conn wide-band-speech
                      cis-central cis-peripheral ll-privacy past-sender past-receiver
 
Note: cis-central is present in BOTH supported and current settings. This is an
Intel BE200. LE Audio streaming works fine on this controller with other LE-Audio
sinks (Galaxy Buds3 Pro), so CIS-Central itself is functional.
 
 
Peripheral
----------
Sony INZONE Buds - LE Audio only, advertises "BR/EDR Not Supported".
  Modalias:   usb:v054Cp0EC1d0206  (VID 0x054C Sony, PID 0x0EC1)
  Appearance: 0x0941 (Earbud)
  CSIP coordinated set (RSI in advertising; CSIS with Set Size / Rank / Lock / SIRK),
  2 members: BUD_1 and BUD_2 (both Static Random).
 
 
Steps to reproduce
-------------------
1. Factory-reset the buds, both out of the case (full CSIP set advertising).
2. bluetoothctl -> scan on -> pair BUD_1.
3. Bond succeeds, then the peripheral disconnects immediately.
 
 
Expected
--------
After bonding + GATT discovery, BlueZ configures an ASE, sets up CIG/CIS, a
PipeWire BAP sink appears, and the link stays up.
 
 
Actual
------
The peripheral terminates the link ~1.1 s after connection-complete with reason
0x13 (Remote User Terminated) - a deliberate disconnect by the device, not a
supervision timeout (0x08). No LE Set CIG Parameters (0x08|0x0062) and no
LE Create CIS (0x08|0x0064) is ever issued.
 
 
Key observation - failing vs. succeeding path
---------------------------------------------
On a minority of attempts the link STAYS UP: ServicesResolved=yes, full LE Audio
GATT resolved (ASCS with 2x Sink ASE + 1x Source ASE, PACS, VCS, CSIS, BASS,
TMAS). The only difference is the connect path: `connect` issued while discovery
is active (bluetoothctl "Scan and connect: yes"), with both set members
advertising, vs. a plain pair/connect after bonding. Same machine, same buds,
same software - only the connect timing differs. This suggests a
connect/idle-handling timing issue rather than a missing capability.
 
 
Ruled out
---------
- Controller / CIS-Central:  BE200, cis-central active (see btmgmt info); works with other LE-Audio sinks.
- Cross-OS:                  same laptop/controller/buds work out of the box on Windows 11.
- LC3 / BAP:                 liblc3 present; BAPSink/lc3 + BAPSource/lc3 registered.
- Experimental:              enabled (BAP endpoints prove it).
- Pairing / security:        SMP completes, encryption AES-CCM, LTK + IRK stored.
- CSIP services:             present and discovered.
- Codec negotiation:         never reached; device drops before any ASE config.
- Reproduced on BlueZ stable and bluez-git, across full reboots.
 
 
Log A - failing attempt, btmon (shortened)
------------------------------------------
> LE Enhanced Connection Complete (Status: Success)
      Role: Central
      Peer: BUD_1 (Static Random)
      Connection interval: 45.00 msec   Supervision timeout: 420 msec
> LE Read Remote Used Features
      Connected Isochronous Stream - Central
      Connected Isochronous Stream - Peripheral
      Connected Isochronous Stream (Host Support)
< SMP: Pairing Request  (SC, Bonding)
> SMP: Pairing Response (NoInputNoOutput, SC, Bonding)
  ... ECDH keys / confirm / random / DHKey check ...
> Encryption Change: Enabled with AES-CCM
@ New Long Term Key (stored) ; New IRK (stored) ; Pair Device: Success
  ... ATT GATT discovery: GAP, GATT, DIS, CSIS(0x1846), CAS(0x1853),
      TMAS(0x1855), BASS(0x184f), ASCS(0x184e), PACS(0x1850), VCS(0x1844) ...
> HCI Event: Disconnect Complete
      Reason: Remote User Terminated Connection (0x13)   # ~1.1 s after connect
 
No LE Set CIG Parameters and no LE Create CIS appear anywhere in the capture.
 
 
Log B - succeeding attempt, bluetoothctl (link stays up)
--------------------------------------------------------
[BUD_1] Scan and connect (yes,no): yes
[CHG] Device BUD_1 Connected: yes
  ... full GATT tree resolves ...
[CHG] Device BUD_1 ServicesResolved: yes
[CHG] Device BUD_1 Modalias: usb:v054Cp0EC1d0206
  # ASCS: 2x Sink ASE (0x2bc4), 1x Source ASE (0x2bc5), ASE Control Point (0x2bc6)
  # PACS, VCS, CSIS (SIRK/Size/Lock/Rank), BASS, TMAS all present; link does not drop.
 
 
Related
-------
- Arch forum, same device, unresolved: https://bbs.archlinux.org/viewtopic.php?id=302495
- Setup followed per PipeWire LE Audio + LC3 wiki:
  https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/LE-Audio-+-LC3-support
 
 
I can provide full btmon captures of both the failing runs on
request. Happy to test patches.
 
Thanks,
Adrian