LESC is not work

Dear Nordic support,

We are bringing up LE Secure Connections as a GAP Central on nRF52832 with SoftDevice S332 (BLE + ANT, nRF5 SDK 14, BLE API v5). The nRF runs the serialization connectivity application (experimental_ant_ble, UART/SPI to an STM32 host). The STM32 computes the LESC DHKey (mbedTLS) and calls sd_ble_gap_lesc_dhkey_reply through the serialization codecs.

Peer: Shimano Di2 (SBIP v3). It requires LESC Just Works (bond=1, mitm=0, lesc=1, IO_CAPS_NONE). A smartphone as Central pairs and encrypts successfully. An air sniffer shows the full LESC SMP sequence, then LL_ENC_REQ / LL_ENC_RSP / LL_START_ENC_*. (Wireshark “bad MIC” after that is expected; the sniffer has no LTK.)

On our product (S332 + serialization, Central):

  • Connection, pairing parameters, public keys, Pairing Confirm/Random, and both DHKey Check PDUs complete on air (same as the phone).
  • Host DHKey was independently verified (ECDH). Serialization encodes SD_BLE_GAP_LESC_DHKEY_REPLY (op=0x81, 36 bytes). SoftDevice returns NRF_SUCCESS.
  • We added logging on the connectivity MCU immediately around sd_ble_gap_lesc_dhkey_reply. The 32-byte key delivered to the SoftDevice matches the host key; sd_err_code = 0.
  • SoftDevice then emits BLE_GAP_EVT_AUTH_STATUS with auth_status = 1 (timeout), lesc = 0bonded = 0error_src = 0 after ~30 s. There is no BLE_GAP_EVT_CONN_SEC_UPDATE.
  • Sniffer: after DHKey Check, no LL_ENC_REQ; empty PDUs until the timeout. The first missing packet is the Central’s LL_ENC_REQ.

We also confirmed:

  • As a GAP Peripheral, the same product can bond with a phone (phone sends LL_ENC_REQ). That path works.
  • Host-side experiments (defer MTU/DLE, defer connection-parameter update, close ANT channels during pairing) did not produce LL_ENC_REQ. There is a ~4 s idle window after DHKey reply before the peer’s conn-param request, so that procedure is not occupying the LL at the moment encryption should start.
  • There is no application API to send LL_ENC_REQ; we understand it must come from the SoftDevice after a successful LESC DHKey.

Question: Is this a known limitation or bug of S332 v5.x as Central (especially with ANT combo and/or serialization) where LESC SMP finishes but the Link Layer encryption procedure is never started? If so, which SoftDevice / SDK combination is known to fix it (e.g. later S332 6.1.x, or S132 on the same nRF52832)?

We can provide sniffer captures (phone vs. product) and UART logs showing the connectivity-side DHKey and AUTH_STATUS. We also have an nRF52832 DK + S132 + SDK 17 and can run an on-chip LESC Central example against the same Di2 if that helps isolate S332 vs. serialization.

Thank you.

Best regards,

 [nRF52832 / S332 version from sd_ble_version_get if you have Image/SD numbers]
 [SDK 14 connectivity example: experimental_ant_ble, pca10040/s332]

Related