Fix: onDisconnect not fired when peer powers off with 0x3E disconnect reason

[Copilot]

In 2.5.0, the connection retry logic for BLE_ERR_CONN_ESTABLISHMENT (0x3E) incorrectly activates when a previously-established connection drops with that reason code — which happens when the peer powers off within the first 6 connection events (the BLE LL "connection establishment phase"). This suppresses onDisconnect entirely, instead calling onConnectFail after up to 60+ seconds of retries (2 retries × 30s timeout). Applications with reconnect logic in onDisconnect never recover.

Changes

• src/NimBLEClient.cpp — In BLE_GAP_EVENT_DISCONNECT, capture wasConnected = (m_connStatus == CONNECTED) before any state mutation:
  • Retry on 0x3E only when !wasConnected — i.e., the connection was never confirmed at the host level. A 0x3E on an established connection is a genuine disconnect, not a retryable establishment failure.
  • Call onDisconnect (not onConnectFail) when wasConnected && rc == 0x3E, so the semantics match what the application observes: a working connection that went away.
  • Apply the same isConnectFail flag consistently to the deleteOnConnectFail / deleteOnDisconnect deletion logic.

// Before fix: retried on 0x3E regardless of whether connection was established
if (rc == connEstablishFailReason && pClient->m_connectFailRetryCount < pClient->m_config.connectFailRetries) { ... }

// After fix: only retry when the connection was never established
const bool wasConnected = (pClient->m_connStatus == CONNECTED);
if (rc == connEstablishFailReason && !wasConnected &&
    pClient->m_connectFailRetryCount < pClient->m_config.connectFailRetries) { ... }

const bool isConnectFail = (rc == connEstablishFailReason && !wasConnected);
if (isConnectFail) {
    pClient->m_pClientCallbacks->onConnectFail(pClient, rc);
} else {
    pClient->m_pClientCallbacks->onDisconnect(pClient, rc);  // now fires correctly for 0x3E post-connect
}

[h2zero]

@copilot how does this address the fact the server device doesn't know about the disconnect?
Also the 0x3E error should not occur unless the connection was not confirmed in the first place.

[Copilot]

@copilot how does this address the fact the server device doesn't know about the disconnect?
Also the 0x3E error should not occur unless the connection was not confirmed in the first place.

The fix addresses the client-side (NimBLEClient) scenario where the peripheral devices are running NimBLEClient and connecting to the central hub. It does not change NimBLEServer's disconnect handling (which already calls onDisconnect for all reasons including 0x3E).

Regarding 0x3E after a confirmed connection: looking at the NimBLE controller code (ble_ll_conn.c), BLE_GAP_EVENT_CONNECT (status=0) is fired by the HCI connection complete event at line 2914 while the LL connection is still in BLE_LL_CONN_STATE_CREATED (line 2814) — before any data PDU is exchanged. The state only transitions to BLE_LL_CONN_STATE_ESTABLISHED when the first packet is received (line 3478). The 0x3E timeout fires if no PDU arrives in the first 6 connection events (line 3055-3057), meaning 0x3E in the disconnect handler always follows a BLE_GAP_EVENT_CONNECT with status=0, so wasConnected is always true at that point.

In 2.4.0, 0x3E called onDisconnect (no retry). In 2.5.0, the new retry code suppresses onDisconnect and calls onConnectFail after retries — breaking any user reconnect logic that lives in onDisconnect. My fix restores the 2.4.0 behaviour: when BLE_GAP_EVENT_CONNECT was already received (wasConnected = true), treat subsequent 0x3E as a disconnect and call onDisconnect.

If the peripheral devices are instead running NimBLEServer (accepting inbound connections from the central), their disconnect handling is unaffected by this PR — could you point me at the specific server-side path that's missing the disconnect event? I reviewed NimBLEServer::handleGapEvent and couldn't find a code path that would drop the 0x3E disconnect without calling onDisconnect.