proper usage of peer manager + advertising and what to do after disconnect

[ms360]

I am using NRF SDK 17.1.0

I inherited some legacy code that was a mess, and rewrote it.

Part 1 - 

First I skipped the peer manager thinking it was not necessary.
Then I re-added the peer manager to a peripheral to allow faster reconnects in the event we lose connection. 
It happens frequently. The device is frequently submerged in water. Without peer manager, reconnection was slow. 

I first was using a manual deactivation of advertising on connect, and activation of advertising on disconnect, and if multiple centrals are nearby, I noticed some cross pairing issues. 
Later, I noticed 3 things 

• The legacy code I inherited never turned off advertising, tho I don't see it advertise in nrf connect while connected
• The legacy code I inherited was skipping 
  pm_handler_disconnect_on_sec_failure in the pm_evt_handler(), I re-enabled it
• I set config.ble_adv_on_disconnect_disabled to false

Between these 2 actions, it seems like the cross pairing issue is gone. 

Question 1&2 - is this the correct way to handle advertise on disconnect? Should I never be turning off advertising after a connection is established? 

Part 2 -

If a central is scanning and see's my peripheral, it tries to connect. 
The central hammers the peripheral and I get an endless loop of 

<warning> app: BLE_GAP_EVT_CONNECTED
<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Encryption, error: 4102
<warning> peer_manager_handler: Disconnecting conn_handle 0.
<warning> app: BLE_GAP_EVT_DISCONNECTED

I expect the security failure given that it isn't paired/bonded. 

Question 3 - If I delete the bonds on the peripheral, start advertising (undirected) and want this new central to connect, It seems like it stops scanning and fails to connect. 
I am trying to determine if this is a bug in my central or the peripheral. Still gathering data. Open to suggestions. 

Thanks!

[Hieu]

Hi ms360,

Question 1&2 - is this the correct way to handle advertise on disconnect? Should I never be turning off advertising after a connection is established? 

There are multiple things at play here so let me go into it a bit slowly.

I set config.ble_adv_on_disconnect_disabled to false

It seems you are using the Advertising Module here rather than direct SoftDevice GAP API. No problem with that, just noting details for later.

The exact behavior desired depends on your requirements. However, most project would like to have the device restart advertising upon disconnection. Regardless, this shouldn't have any issue related to pairing.

The legacy code I inherited never turned off advertising, tho I don't see it advertise in nrf connect while connected

Connectable advertising is stopped once the connection request is received. This is the default behavior.

Do you expect the connectable advertising to continue? Is the device expected to support multiple concurrent centrals?

The legacy code I inherited was skipping 

pm_handler_disconnect_on_sec_failure in the pm_evt_handler(), I re-enabled it

No comment on this. This depends on your requirement.

Between these 2 actions, it seems like the cross pairing issue is gone. 

I need some clarifications here. What exactly is the cross-pairing issue? 

Does the issue disappear after you set ble_adv_on_disconnect_disabled() and implement pm_handler_disconnect_on_sec_failure()? Or after you do either of those?

<warning> app: BLE_GAP_EVT_CONNECTED
<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Encryption, error: 4102
<warning> peer_manager_handler: Disconnecting conn_handle 0.
<warning> app: BLE_GAP_EVT_DISCONNECTED

I expect the security failure given that it isn't paired/bonded. 

Question 3 - If I delete the bonds on the peripheral, start advertising (undirected) and want this new central to connect, It seems like it stops scanning and fails to connect. 
I am trying to determine if this is a bug in my central or the peripheral. Still gathering data. Open to suggestions. 

Refer to this past DevZone case:  peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Encryption, error: 4102 .

The steps you described here matches what is discussed in that case, where the bond information is only deleted on one device. If the other device isn't programmed to clear the bond information on this kind of failure, the failure will persist.

Could that be the case?

Hieu

[ms360]

Hieu, thank you. That sounds like the exact issue. I'm trying to detect this on the central but I'm not getting a clear event to indicate. Other than  BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION 0x13 /**< Remote User Terminated Connection. */

I logged all the PM events and I don't see an auth or sec failure. Is there something I can trigger the bonding info delete on? 

[00:00:55.023,498] <error> ble_scan: Paired Peripheral FOUND with RSSI: -19 max: -23
[00:00:55.023,803] <info> ble_scan: Connecting
[00:00:55.067,626] <info> app: Connecting to target 079258EAD4E1
[00:00:55.067,687] <error> app: PM ERROR 1
[00:00:55.067,871] <error> app: PM ERROR 6
[00:00:55.068,237] <error> app: PM ERROR 2
[00:00:55.068,237] <info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change
[00:00:55.068,298] <error> app: PM ERROR 9
[00:00:55.068,298] <error> app: PM ERROR 0
[00:00:55.068,908] <error> app: PM ERROR 15

[Hieu]

Hi ms360,

Is the Peer Manager error 4102 still an issue or not?

On the nRF device, you can delete bonds using the pm_peers_delete() function.

Regarding the above log, what are the things that produce the "PM ERROR <err num>" lines?

Hieu

[ms360]

Thank you Hieu. 

• I still get the error 4102 because my central cannot identify a regular disconnect from a security failure. 
  • The central doesn't seem to know it was 'hung up on' regarding a pair auth failure. 
  • All I can find so far is BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION
• The PM Errors came from the default case in the pm_evt_handler

static void pm_evt_handler(pm_evt_t const * p_evt)
{
    pm_handler_on_pm_evt(p_evt);
    if (p_evt->conn_handle == BondedDevice_handle) { 
        pm_handler_disconnect_on_sec_failure(p_evt);
    }
    pm_handler_flash_clean(p_evt);
    
    ret_code_t err_code;
    switch (p_evt->evt_id)
    {


        case PM_EVT_PEERS_DELETE_SUCCEEDED:
            // Bonds are deleted. Start scanning.
            scan_start();
            break;
        case PM_EVT_CONN_SEC_FAILED:
            NRF_LOG_ERROR("PM_EVT_CONN_SEC_FAILED");
            break;
        default:
            NRF_LOG_ERROR("PM ERROR %d", p_evt->evt_id);
            break;
    }
}

[Hieu]

Hi ms360,

What is the central device? Are there no way to delete the bond information from it?

If you try to connect to the nRF device using a new central, such as your phone, do you still get the error 4102?

Regarding the LOG_ERROR on the default case, I recommend lowering it down to the NRF_LOG_INFO or NRF_LOG_WARNING level and maybe change the message. It just signifies unhandled PM events, not an error.