NimBLEClient: updateConnParams() prevents LL Response Timeout disconnects, but reported connection parameters remain unchanged

[vlucent]

Description

I'm seeing some unexpected behavior when using NimBLEClient as a central.

Calling:

pClient->updateConnParams(12, 12, 0, 150);

prevents a disconnect that otherwise occurs after approximately 40 seconds:

reason=546
LL Response Timeout

However, the reported connection parameters appear unchanged before and after the update request.

Environment

• NimBLE-Arduino version: 2.5.0
• ESP32 variant: esp32-c6
• Peripheral: BLE IR thermometer 985c-APP by holdpeak

Configuration

NimBLEDevice::setPower(ESP_PWR_LVL_P9);
pClient->setConnectionParams(12, 12, 0, 150);

Connection Parameter Output

Connection Info before and after updateConnParams():

class ClientCallbacks : public NimBLEClientCallbacks {
    void onConnect(NimBLEClient* pClient) override { 
        Serial.println(pClient->getConnInfo().toString().c_str());
        pClient->updateConnParams(12, 12, 0, 150);
        Serial.println(pClient->getConnInfo().toString().c_str());
    }
}

Output (connInfo is unchanged before and after updateConnParams()):

  Address: XX:XX:XX:XX:XX:XX
  ID Address: XX:XX:XX:XX:XX:XX
  Connection Handle: 0
  Connection Interval: 40.0 ms
  Connection Timeout: 6000 ms
  Connection Latency: 0
  MTU: 160 bytes
  Role: Master
  ...

Connection info after 30 seconds (via ble_gap_conn_desc):

ble_gap_conn_desc desc;
if (ble_gap_conn_find(connHandle, &desc) == 0) {
    Serial.printf("Interval: %d\n", desc.conn_itvl);
    Serial.printf("Latency: %d\n", desc.conn_latency);
    Serial.printf("Timeout: %d\n", desc.supervision_timeout);
}

ble_gap_conn_desc output (which translates to the same values 40ms interval, 6000ms timeout):

Interval: 32
Latency: 0
Timeout: 600

Verbose Logs

Without updateConnParams():

[BLE] connection success
Connected to: XX:XX:XX:XX:XX:XX RSSI: -65
...
D NimBLEClient: >> handleGapEvent BLE_GAP_EVENT_L2CAP_UPDATE_REQ
D NimBLEClient: Peer requesting to update connection parameters
D NimBLEClient: MinInterval: 16, MaxInterval: 32, Latency: 0, Timeout: 600
D NimBLEClientCallbacks: onConnParamsUpdateRequest: default
D NimBLEClient: Accepted peer params
...(~40 sec later)
D NimBLEClient: >> handleGapEvent BLE_GAP_EVENT_CONN_UPDATE
E NimBLEClient: Update connection parameters failed.
D NimBLEClient: >> handleGapEvent BLE_GAP_EVENT_DISCONNECT
D NimBLEClient: disconnect; reason=546, LL Response Timeout

With updateConnParams():

[BLE] connection success
Connected to: XX:XX:XX:XX:XX:XX RSSI: -66
...
D NimBLEClient: >> handleGapEvent BLE_GAP_EVENT_CONN_UPDATE
I NimBLEClient: Connection parameters updated.
...
D NimBLEClient: >> handleGapEvent BLE_GAP_EVENT_L2CAP_UPDATE_REQ
D NimBLEClient: Peer requesting to update connection parameters
D NimBLEClient: MinInterval: 16, MaxInterval: 32, Latency: 0, Timeout: 600
D NimBLEClientCallbacks: onConnParamsUpdateRequest: default
D NimBLEClient: Accepted peer params

Questions

1. Are getConnInfo() and ble_gap_conn_find() expected to report the active negotiated connection parameters?
2. If so, why do the reported values remain unchanged after updateConnParams() and a subsequent BLE_GAP_EVENT_CONN_UPDATE?
3. Is BLE_GAP_EVENT_CONN_UPDATE expected to occur before a later BLE_GAP_EVENT_L2CAP_UPDATE_REQ?
   Why would an explicit updateConnParams() call prevent the LL Response Timeout disconnect if the reported connection parameters do not appear to change?