search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.52k stars 6.45k forks source link

Bluetooth: Controller: ISO: Retry sync to BIG after incorrect broadcast code only provides a single SDU #77680

Open Thalley opened 3 weeks ago

Thalley commented 3 weeks ago

Describe the bug If an application provides the incorrect broadcast code when syncing to an encrypted BIG, then retrying with the correct code correctly syncs to the BIG but only a single SDU per BIS is received.

To Reproduce Steps to reproduce the behavior:

  1. Checkout https://github.com/zephyrproject-rtos/zephyr/pull/77642
  2. Build and run https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/bsim/bluetooth/audio/test_scripts/bap_broadcast_audio_encrypted.sh
  3. See error only a single SDU received and the test fails

Expected behavior Expect that providing the correct code after a sync failure will work. Resyncing to a BIG generally works if both attempts work.

Impact Seems to be an irreversible state from the host, so quite significant.

Logs and console output

d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: hci_le_big_sync_established: BIG[0] 0x825b620 sync established, status 0x00 
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: bt_iso_connected: 0x825b2a0
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: bt_iso_chan_set_state_debug: chan 0x825ff40 iso 0x825b2a0 connecting -> connected
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_bap_broadcast_sink: broadcast_sink_iso_connected: stream 0x82535c0
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_bap_broadcast_sink: broadcast_sink_set_ep_state: ep 0x8262600 id 0x00 qos-configured -> streaming
d_01: @00:00:22.825207  Stream 0x82535c0 started
d_01: @00:00:22.825207  Could not get octets per frame: -61
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: bt_iso_connected: 0x825b37c
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: bt_iso_chan_set_state_debug: chan 0x825ffd0 iso 0x825b37c connecting -> connected
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_bap_broadcast_sink: broadcast_sink_iso_connected: stream 0x8253604
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_bap_broadcast_sink: broadcast_sink_set_ep_state: ep 0x826276c id 0x00 qos-configured -> streaming
d_01: @00:00:22.825207  Stream 0x8253604 started
d_01: @00:00:22.825207  Could not get octets per frame: -61
d_01: @00:00:22.825207  Waiting for data
d_01: @00:00:22.837789  [0]: Incoming audio on stream 0x82535c0 len 30 and ts 22830022
d_01: @00:00:22.837789  [0]: Incoming audio on stream 0x8253604 len 30 and ts 22830022
d_00: @00:00:23.107790  Sent with seq_num 2300
d_00: @00:00:23.107790  Sent with seq_num 2300
d_00: @00:00:24.107790  Sent with seq_num 2400
d_00: @00:00:24.107790  Sent with seq_num 2400
d_00: @00:00:25.107790  Sent with seq_num 2500
d_00: @00:00:25.107790  Sent with seq_num 2500
d_00: @00:00:26.107790  Sent with seq_num 2600

Environment (please complete the following information):

Additional context N/A

Thalley commented 2 weeks ago

We may actually just be unable to resync to encrypted broadcast source regardless of whether the broadcast code is correct or not, as https://github.com/zephyrproject-rtos/zephyr/pull/75491 is failing to a similar of the same issue