[bluez/bluez] 952b53: ranging: Route CS subevent results by connection a...

["github-actions[bot]" <noreply@github.com>]

  Branch: refs/heads/1176540
  Home:   https://github.com/bluez/bluez
  Commit: 952b535b9f935612cf5b091767b28f944c6a1e66
      https://github.com/bluez/bluez/commit/952b535b9f935612cf5b091767b28f944c6a1e66
  Author: Cheng Jiang <cheng.jiang@oss.qualcomm.com>
  Date:   2026-09-30 (Wed, 30 Sep 2026)

  Changed paths:
    M profiles/ranging/rap_hci.c
    M src/shared/rap.c

  Log Message:
  -----------
  ranging: Route CS subevent results by connection and configuration

bt_rap_attach_hci() allocates a state machine per device and registers the
CS subevent handlers of each one on the shared bt_hci. LE Meta subevents
are dispatched with queue_foreach() over every registered handler, so each
CS Subevent Result is delivered to all of them, not only to the device the
event belongs to.

The Subevent Result and Subevent Result Continue handlers then passed their
own sm->rap on without checking which connection reported the event, unlike
every other handler in rap_hci.c, which resolves it with
find_mapping_by_handle() and returns when the connection is not its own.
The Connection_Handle was parsed into the event and never read again, in
rap_hci.c or in shared/rap.c.

With two CS connections up, one set of ranging data was therefore consumed
by both sessions and sent out over both peers' RAS characteristics. Resolve
the mapping and drop the subevent when the connection is not tracked.

handle_local_subevent_result() and parse_cs_local_initiator_data() also
took a config_id they never checked against the tracked one, so subevents
belonging to a second CS configuration on the same connection were
appended to the procedure of the first. Ignore a subevent whose config_id
does not match the tracker, once the tracker has one.

Assisted-by: Claude:claude-opus-4.8



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