nimble/host: L2CAP fallback for LL conn param rejection#2192
Open
gmarull wants to merge 1 commit intoapache:masterfrom
Open
nimble/host: L2CAP fallback for LL conn param rejection#2192gmarull wants to merge 1 commit intoapache:masterfrom
gmarull wants to merge 1 commit intoapache:masterfrom
Conversation
sjanc
reviewed
Apr 7, 2026
nimble/host/src/ble_gap.c
Outdated
| * If the controller rejects the LL update with "Unsupported Remote | ||
| * Feature" and we are the slave, fall back to L2CAP signaling. This | ||
| * can happen when the peer advertises CONN_PARAM_REQUEST support at | ||
| * the host level but the local controller does not support the 4.1 LL |
Contributor
There was a problem hiding this comment.
should this comment be about peer's controller, not local controller?
as per spec:
Unsupported Remote Feature (0x1A)
"The Controller is the Peripheral and the local Controller supports the Connection Parameters Request procedure but the peer Controller does not."
When the peripheral calls ble_gap_update_params() and the peer's supported features indicate CONN_PARAM_REQUEST support, NimBLE sends the LE Connection Update HCI command. However, if the peer's controller does not support the BLE 4.1 LL Connection Parameters Request procedure, the HCI command is rejected synchronously with BLE_ERR_UNSUPP_REM_FEATURE (0x1a). NimBLE already handles this error asynchronously in ble_gap_rx_update_complete() by falling back to L2CAP signaling, but the synchronous rejection path had no such fallback, causing the update to fail and be retried futilely by upper layers. Add a synchronous fallback: when ble_gap_update_tx() returns BLE_ERR_UNSUPP_REM_FEATURE and the local device is the slave, switch to the L2CAP Connection Parameter Update Request procedure. Signed-Off-By: Gerard Marull-Paretas <gerard@teslabs.com>
gmarull
force-pushed
the
conn-update-fix
branch
from
824461b to
a9668cd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the peripheral calls ble_gap_update_params() and the peer's supported features indicate CONN_PARAM_REQUEST support, NimBLE sends the LE Connection Update HCI command. However, if the local controller does not support the BLE 4.1 LL Connection Parameters Request procedure (e.g. an external controller with limited feature set), the HCI command is rejected synchronously with BLE_ERR_UNSUPP_REM_FEATURE (0x1a).
NimBLE already handles this error asynchronously in ble_gap_rx_update_complete() by falling back to L2CAP signaling, but the synchronous rejection path had no such fallback, causing the update to fail and be retried futilely by upper layers.
Add a synchronous fallback: when ble_gap_update_tx() returns BLE_ERR_UNSUPP_REM_FEATURE and the local device is the slave, switch to the L2CAP Connection Parameter Update Request procedure.