1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

I use nRF Connect to connect to nRF52832 device. 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link. Why 1st and 2nd connection are different?

The following is log message of nRF52832 device.

00> <info> app: POWER_ON.
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 185 bytes on connection 0x0.
00> <info> app: BLE_GAP_EVT_CONNECTED (1st connection)
00> <debug> app: state=1
00> <debug> nrf_ble_gatt: ATT MTU updated to 185 bytes on connection 0x0 (response).
00> <debug> app: _securityRequestHandler
00> <info> app: BLE_GAP_EVT_SEC_PARAMS_REQUEST
00> <info> app: PM_EVT_CONN_SEC_SUCCEEDED
00> <info> app: Connection secured: role: 1, conn_handle: 0x0, procedure: 1.
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 185 bytes on connection 0x0.
00> <info> app: PM_EVT_BONDED_PEER_CONNECTED
00> <info> app: BLE_GAP_EVT_CONNECTED (2nd connection)
00> <debug> app: state=1
00> <debug> nrf_ble_gatt: ATT MTU updated to 185 bytes on connection 0x0 (response).

Parents Reply
  • It does not bond automatically with nRF Connect by default. First connect, like you did and then:

    1. Click the gears icon on the device
    2. Click "Pair..."
    3. Check the "Bonding" checkbox
    4. Click the "Pair" button

    Now the devices are bonded.

    If you now disconnect and reconnect again the link will be automatically encrypted as the devices was bonded from before.

    (You can also change the nRF Connect configuration by clicking the gears icon on the device close to the right, which is the one used for connectivity. There select "Security parameters..." and check the "Perform bonding" box. This is used by default if the peripheral request security, which is the case here, and then bonding will be automatic".)

    Both of the above procedures works with any Bluetooth LE device that supports bonding, like for instance the ANCS example in the SDK. However, if you look at the log from nRF while pairing/bonding you get a timeout, and that is because of your main loop where you wait for RTT etc, so your idle state handler with the here important app_sched_execute() does not run. So I fixed it simply by removing everything in your main loop except for the call to idle_state_handle().

    In a nutshell, the root cause of the issue you are seeing is that you block in your main loop, preventing the app scheduler from running.

Children
Related