Peer Manager stale connection handles and pm_peers_delete()

[BrianK]

1) With SDK14 and SDK15, we're seeing that the connection handle for the last bonded connection is kept indefinitely until reset. The connection handle does not get set to invalid when the corresponding peer has disconnected. I am definitely seeing the BLE_GAP_EVT_DISCONNECTED, which I would assume should invalidate the handle.

I'm not sure if this is by design.

2) This means that pm_peers_delete() will not delete all bonds, because it stops when it encounters a valid connection handle for a bond.

It (1) is by design, then it would be useful for pm_peers_delete() to check if it the handle corresponds to an active connection, perhaps with

get_connection_by_conn_handle()and delete it if not actually connected.

If that is not a reliable test, it would still be useful to skip the peer that has a valid handle, and continue deleting the rest.

We're considering this alternate implementation of im_peer_free(). 

static ret_code_t my_im_peer_free(pm_peer_id_t peer_id)

{

uint16_t conn_handle;

ret_code_t ret = NRF_SUCCESS;

conn_handle = im_conn_handle_get(peer_id);

if ((conn_handle != BLE_CONN_HANDLE_INVALID))

{

ret = pdb_peer_free(peer_id);

if (NRF_SUCCESS = ret)

{

peer_id_set(conn_handle, PM_PEER_ID_INVALID);

}

}

return ret;

}

 

[BrianK]

rather: if (NRF_SUCCESS == ret)

[Edvin]

Hello,

Does your application set the conn_handle to BLE_CONN_HANDLE_INVALID on the BLE_GAP_EVT_DISCONNECTED event?

Best regards,

Edvin

[BrianK]

Hi Edvin,

I had expected the peer manager would set the handle to invalid before forwarding the message to my application handler. So I thought it was by design to leave it, or a bug in the PM. The examples do not invalidate the connection handle associated with the peer bond. They only manage their own handles that are kept in their services.

Thanks,

Brian

[Edvin]

Hello Brian,

I am sorry, I don't see the issue with the original implementation.

I just did a test using the ble_app_keyboard example.

Started with empty bonding information. Connected via nRF Connect for Desktop. Modified button 3 to disconnect if connected, and print the pm_peers_count if not. Button 4. deletes bonding information.

1: Example started.

2: Pressed button 3. Prints count = 0.

3: Connected via nRF Connect, bonded.

4: pressed button 3 -> Disconnects. 

5: pressed button 3 again, prints: count = 1.

6: pressed button 4. Deletes bonding information.

7: pressed button 3, prints count = 0.

I attached the main.c from this test. Does this behave the way you expect, or do you want it to behave differently?

main.c (SDK15.0.0\examples\ble_peripheral\ble_app_hids_keyboard\main.c)

BR,

Edvin

[BrianK]

The keyboard example is a different type of device, since it behaves as a device that has a single bond and should should be auto-connected. Once it has a bonded peer it only allows that peer to connect. The example is also deleting bonds on boot. It's just not a good example.

nRF Connect 2.6.1 gives me NRF_ERROR_INTERNAL with macOS and Windows 10 when I try to pair with bonding to the Nordic_Keyboard.

When I connect with iOS I see a lot of strange behavior and the firmware crashes often when pressing the buttons (PCA 10040) and doesn't seem to be deleting the bonds with button press, but anyhow iOS is also trying to auto connect so I can't try with multiple stored bonds.

Anyway, our device does not behave this way, and it is not a HID device. It may have a number of bonds stored at a time, and any one of those paired devices may connect to it, depending on the context.

With a number of CLI commands for showing peer info, I can definitely see that the last connected peer has a valid connection_handle indefinitely, or until reset. This happens with SDK14 and 15, it should be easily reproducible there.

I'm running out of time to devote to this, especially since the change to im_peer_free() is working for us now.