pm_conn_sec_status_get bug?

[Stayhungry]

phenomenon:

When master successfully encrypts using previous binding information, pm_evt_handler in main.c receives a PM_EVT_CONN_SEC_SUCCEEDED event and gets a bonded state of 0 using pm_conn_sec_status_get.

My point is:

After the master has successfully encrypted using the previous binding information, the slave should also be in the bonded state. By looking at peer_manager.c, since the above process is considered PM_LINK_SECURED_PROCEDURE_ENCRYPTION, the bonded flag is not set in pm_sm_evt_handler

Is it my understanding wrong? If I did not understand it, how to fix it?

[Øyvind Rønningstad]

No problem. The bonded flag is also set when PM_EVT_BONDED_PEER_CONNECTED. The bug in this case is that the PM_LINK_SECURED_PROCEDURE_ENCRYPTION event is overwriting the flag from 1 to 0.

It might be more intuitive if you do

if (!ble_conn_state_user_flag_get(p_sm_evt->conn_handle, m_bonded_flag_id))
{
    ble_conn_state_user_flag_set(p_sm_evt->conn_handle, m_bonded_flag_id, bonded);
}

instead, but the result should be the same.

[Stayhungry]

Thank you very mcuh.

Another question, if this change will cause another bug? Just pairing without bonding

[Øyvind Rønningstad]

Should be ok. Just pairing is its own procedure type, separate from bonding.

[Elias]

What is the analogous modification for SDK 13.1?

[Petter Myhre]

SDK 31.1 ?

[Elias]

excuse me, 13.1*