• State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 62 subscribers
  • Views 1322 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 124320
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Restart encryption without slave supporting encryption best practice

Valer_I

Hello, My question is about the case when initiator device attempting to restart encryprion with previously bonded responding device that lost the bond context. As usual, after reconnection softdevice fires BLE_GAP_EVT_SEC_INFO_REQUEST callback to make application load bond context to restart encryption. But what to do if responder device does not have bond context?

  1. Case1 : respond sd_ble_gap_sec_info_reply( conn_handle, NULL, NULL, NULL); that leads to emmediate disconnection by initiating device on any tried platform (Windows, Androidm, iOS, MACos); The ble flow is next:

     ENC_REQ 
 ENC_RSP
 START_ENC_REQ
 START_ENC_RSP

    <No START_ENC_RSP from responder and disconnection by timeout >

  2. Case2: Try to start pairing: We have sd_ble_gap_authenticate() in softdevice that send SMP_SECURITY_REQUEST to initiator. but it still does not work because this command of another protocol (SMP, not LMP) and it seems that initiator waiting for LMP responce first.

  3. Case3:

Core v4.2 [Vol 6, Part D] page 155 "6.9 START ENCRYPTION WITHOUT SLAVE SUPPORTING ENCRYPTION"

, as stated there the correct answer in this case should be LL_REJECT_IND. And I tried it on other BLE stack and it works in case of Android based initiator device. How can we do this with Softdevice?

An example of the best practice will be appreciated.

Related