Controller: ACL packets NACKed after Data Length Update

[ahmedmoheb-nordic]

Describe the bug
When central is connected to multiple peripherals and the MTU LL data length is increased to 247 bytes, central gets notifications only from the last connected peripheral

To Reproduce
Steps to reproduce the behavior:

1. Central connects to more than one peripheral
2. For each connection, set the connection interval to be 25 ms
3. For each connection, increase the MTU above 190 bytes
4. Send notifications from connected peripherals other than the last connected one

Expected behavior

1. Central receives notifications from the last connected peripheral
2. Notifications from peripherals other than the last connected one are missed
3. Peripherals that aren't communicating disconnect with time out disconnection reason

Additional context
Issue doesn't occur if the connection interval is increased or the notification data size is below 160 bytes

Environment

• OS: Ubuntu 22.04
• Toolchain : Zephyr SDK 0.15.1
• Commit SHA 3607a05fbaf1d85a1e11d19c6ff33b869c5e88bb
• PR Bluetooth: Central misses notifications from connected peripherals after increasing MTU #52392

[jori-nordic]

I think it's a controller issue, the test works fine (there were some logic errors) when peripherals are compiled with CONFIG_BT_AUTO_DATA_LEN_UPDATE=n.

It seems the central controller has issues ACK-ing one of the peripheral after switching to the max LL packet length. When the LL data length stays at 27, there are no issues whatsoever.

@kruithofa and @cvinayak To reproduce:

• check out this branch: https://github.com/jori-nordic/zephyr/tree/long-packets-no-ack
• run the build&test script tests/bluetooth/bsim_bt/bsim_test_conn_stress/tests_scripts/conn_stress.sh

[ahmedmoheb-nordic]

I've tested the same scenario using the desktop application "nrf connect for desktop Bluetooth Low Energy" in place of the central device while keeping the same peripherals and following the same behavior of the central application and there were no issues found.

So, I support @jori-nordic assumption that the central controller has an issue

[kruithofa]

might be fixed by PR #52012 and #53095, I will reproduce the issue first, and see if these PRs fix it

[kruithofa]

@ahmedmoheb-nordic @jori-nordic PR #52012 fixes this issue, but requires that the event-length update feature is enabled by adding following 2 lines to the prj.conf files:
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_EVENT_LEN_UPDATE=y
@ahmedmoheb-nordic can you confirm?