nimble/host: L2CAP fallback for LL conn param rejection

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.

Signed-Off-By: Gerard Marull-Paretas <[email protected]>
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Author: gmarull

nimble/host/src/ble_gap.c

@@ -6347,6 +6347,19 @@ ble_gap_update_params(uint16_t conn_handle,
         rc = 0;
     } else {
         rc = ble_gap_update_tx(conn_handle, params);
+
+        /*
+         * 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
+         * Connection Parameters Request procedure.
+         */
+        if (rc == BLE_HS_HCI_ERR(BLE_ERR_UNSUPP_REM_FEATURE) &&
+                !(conn->bhc_flags & BLE_HS_CONN_F_MASTER)) {
+            l2cap_update = 1;
+            rc = 0;
+        }
     }
 
 done: