NimBLE: Exchanging MTU breaks when maximum number of concurrent connections is set to 1

[Henry Hunt <he...@seamlessdigital.com>]

Hi all,

I’m working on an ESP32-based Bluetooth LE peripheral using the NimBLE stack (ESP-IDF version 4.4.2) and have come across an issue that occurs when the maximum number of concurrent connections is set to 1 (but not 2 or 3). In this case, performing an MTU exchange only works once ever, until the device is power cycled. Following that second MTU exchange, other BLE operations (such as service discovery or reading characteristics) that are done during the same connection do not succeed.

The issue is easily reproducible with the existing bleprph example:


  *   Create a new ESP project using the bleprph template
  *   In SDKConfig, change “maximum number of concurrent connections” from 3 to 1
  *   Using the nRF Connect mobile app:
     *   Connect to the peripheral
     *   Request an MTU exchange from the menu. The requested MTU value is shown in the ESP serial output.
     *   Disconnect, reconnect, and perform another MTU exchange. The MTU value (which comes from the BLE_GAP_EVENT_MTU event) shown in the ESP serial output is 0.
     *   Select “read characteristics” in the menu. See that there is a GATT error of 0x85 after some time and the connection terminates.
     *   Reconnect and try "read characteristics" again. See that it completes successfully.
     *   Perform another MTU exchange and see 0 in the ESP serial output
     *   Try "read characteristics" again and see that it fails.

Thoughts?

Thanks,
Henry