• State Verified Answer
  • Replies 14 replies
  • Subscribers 25 subscribers
  • Views 1092 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 269171
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

When are peer managers connection handles invalidated?

user84602

Hi,

I have a central that uses PM to connect to some peripherals.

If I connect to a peer (connection handle 0), and disconnect this device (e.g. by shutting it off). I receive BLE_GAP_EVT_DISCONNECTED and all works fine.

But later when I call

pm_conn_handle_get(peerId, &connHandle);

the connection handle I get is still 0 (zero). But it is not a valid connection handle, since e.g. sd_ble_gap_disconnect() fails with BLE_ERROR_INVALID_CONN_HANDLE. I would expect that om_conn_handle_get() returns me BLE_CONN_HANDLE_INVALID.

Although if I connect to the device 1 (connection handle 0), then disconnect it and connect device 2 (connection handle 0, too because it is reused), pm_conn_handle_get() returns BLE_CONN_HANDLE_INVALID.

In my case this leads to a issue where I think the peer is still connected because the connection handle is valid, but in fact it is not and sd_ble_gap_disconnect() returns BLE_ERROR_INVALID_CONN_HANDLE. Sure, I could ignore this error code, but then something else could go wrong without me noticing it.

I there a way to update the peer manager on disconnects?

Best regards

Parents
  • 0
    mgux said:
    ble_conn_state_status() checks the valid_flags and connected_flags. This fixes my problem.

     Yeah, I see now that disconnected links are first invalidated when a device connects again (record_purge_disconnected() called on BLE_GAP_EVT_CONNECTED in ble_conn_state.c). I haven't looked into why it's implemented like this yet, but an alternative to your patch, could be to call ble_conn_state_status(connHandle) in your application code, and based on the return value of this, then do a disconnect and delete the bond info. With this approach, you don't need to modify the id_manager.c file

  • 0 in reply to user15146

    Yes that would be possible too.

    Though this looks like a bug in the SDK to me. It would be nice if you could report back when you know why it's implemented like this.

  • 0 in reply to user84602

    I found a reason why it was implemented like this.

    im_peer_free() uses im_conn_handle_get() and this does not work for disconnected peers with my fix.

    But then the docs of pm_peer_handle_get() are wrong:

     * @param[out] p_conn_handle  Connection handle, or @ref BLE_CONN_HANDLE_INVALID if the peer
 *                            is not connected.

    On the other hand the docs for im_conn_handle_get() states that the conn_handle can refer to a recently disconnceted connection.

     * @return The corresponding connection handle, or @ref BLE_CONN_HANDLE_INVALID if none could be
 *         resolved. The conn_handle can refer to a recently disconnected connection.

Reply
  • 0 in reply to user84602

    I found a reason why it was implemented like this.

    im_peer_free() uses im_conn_handle_get() and this does not work for disconnected peers with my fix.

    But then the docs of pm_peer_handle_get() are wrong:

     * @param[out] p_conn_handle  Connection handle, or @ref BLE_CONN_HANDLE_INVALID if the peer
 *                            is not connected.

    On the other hand the docs for im_conn_handle_get() states that the conn_handle can refer to a recently disconnceted connection.

     * @return The corresponding connection handle, or @ref BLE_CONN_HANDLE_INVALID if none could be
 *         resolved. The conn_handle can refer to a recently disconnected connection.

Children
Related
Terms of service