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 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>

Author: gmarull

nimble/host/src/ble_gap.c

@@ -6344,6 +6344,18 @@ 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
+         * happens when the local controller supports the Connection Parameters
+         * Request procedure but the peer's controller does not.
+         */
+        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: