[bluez/bluez] c8a8a1: shared/bap: Fix rejecting re-attach of the same fd

[bluez/bluez] c8a8a1: shared/bap: Fix rejecting re-attach of the same fd

[ferose]

  Branch: refs/heads/1125740
  Home:   https://github.com/bluez/bluez
  Commit: c8a8a1b931bbdf2f7de7142d4bd0836aec76cc93
      https://github.com/bluez/bluez/commit/c8a8a1b931bbdf2f7de7142d4bd0836aec76cc93
  Author: Ferose <ferose2@gmail.com>
  Date:   2026-07-11 (Sat, 11 Jul 2026)

  Changed paths:
    M src/shared/bap.c

  Log Message:
  -----------
  shared/bap: Fix rejecting re-attach of the same fd

When the remote's STREAMING ASE notification arrives before
iso_connect_cb() fires, the race handler in bap_state()
(profiles/audio/bap.c) already attaches the io to the stream; the
comment there notes "Order of STREAMING and iso_connect_cb() is
nondeterministic". When iso_connect_cb() then calls
bt_bap_stream_set_io() with the same fd, the guard in
bap_ucast_set_io() sees an attached, non-connecting io and returns
false. iso_connect_cb() treats that as fatal:

  profiles/audio/bap.c:iso_connect_cb() Unable to set IO
  profiles/audio/transport.c:bap_state_changed() Unable to get stream IO

and tears down a CIS that btmon shows was established successfully
(CIS Established status 0, both ISO data paths set up). With a device
whose STREAMING notifications consistently win the race, streaming is
never possible.

Treat re-attaching the fd that is already attached as a no-op success,
without re-running the per-stream state actions (which would send a
duplicate Receiver Start Ready to a linked source ASE). Attaching a
different fd to a non-connecting io remains an error.

Fixes: https://github.com/bluez/bluez/issues/2223



To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications