This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bonding information issue when only one side the bonding is delete

Hi,

sometimes not always, the function peer_id_is_allocated return false and this causes an ASSERT of device, because a NRF_ERROR_INVALID_PARAM is returned by pdb_write_buf_get. And Peer_Manager return an assert.

Someone can help to me, why this happens?

Thanks, Anna

Parents
  • Hi Petter,

    now i can reproduce the assert sistematically. I try to explain the flow:

    I need to have a bonding one to one (every device can bonding with one phone) so i have added a whitelist. After i have needed to delete the bonding information if the user lose your phone for example and need to bonding with an other phone

    I have three scenario now, that i need to consider:

    1. User delete bonding information on both side ( APP and phone) ALL WORKS OK

    2. User delete bonding on device side and forgot to delete on phone side, the device disconnect as long as the user don't delete the bonding information, also on phone side. ALL WORKS OK

    3. User delete bonding information on phone side and forgot on device side. In this case i have need to change in the peer menager the case:

      case PM_EVT_CONN_SEC_CONFIG_REQ: { // Allow pairing request from an already bonded peer. pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true}; // pm_conn_sec_config_t conn_sec_config = {.allow_repairing = false}; pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config); } break;//PM_EVT_CONN_SEC_CONFIG_REQ

    because if i don't change it the nrf52 cotinue to reject the pairing, also if i delete the bonding information. So i have set the allow_pairing= true; Note that this think it was necessary only after i have add to whitelist on mi FW design. Before add whitelist, i can bonding with a device already bondend, ( do you see any reason?)

    Meanwhile, the step that reset my device is:

    • Bonding parinig first times
    • Delete bonding only on phone side, set the allow_pairing = true, i can pairing and bonding again without a problem
    • Delete bonding and pairing on both side cause a reset.

    Have you any idea, about this strange bahaviour?

    regards, Anna

Reply
  • Hi Petter,

    now i can reproduce the assert sistematically. I try to explain the flow:

    I need to have a bonding one to one (every device can bonding with one phone) so i have added a whitelist. After i have needed to delete the bonding information if the user lose your phone for example and need to bonding with an other phone

    I have three scenario now, that i need to consider:

    1. User delete bonding information on both side ( APP and phone) ALL WORKS OK

    2. User delete bonding on device side and forgot to delete on phone side, the device disconnect as long as the user don't delete the bonding information, also on phone side. ALL WORKS OK

    3. User delete bonding information on phone side and forgot on device side. In this case i have need to change in the peer menager the case:

      case PM_EVT_CONN_SEC_CONFIG_REQ: { // Allow pairing request from an already bonded peer. pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true}; // pm_conn_sec_config_t conn_sec_config = {.allow_repairing = false}; pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config); } break;//PM_EVT_CONN_SEC_CONFIG_REQ

    because if i don't change it the nrf52 cotinue to reject the pairing, also if i delete the bonding information. So i have set the allow_pairing= true; Note that this think it was necessary only after i have add to whitelist on mi FW design. Before add whitelist, i can bonding with a device already bondend, ( do you see any reason?)

    Meanwhile, the step that reset my device is:

    • Bonding parinig first times
    • Delete bonding only on phone side, set the allow_pairing = true, i can pairing and bonding again without a problem
    • Delete bonding and pairing on both side cause a reset.

    Have you any idea, about this strange bahaviour?

    regards, Anna

Children
No Data
Related