Central scanning with whitelist

[Karol D]

Hello,

I have an application to develop in which Central device is scanning with use of whitelist if it is not connected but have saved peers.  If peer list is empty, device shouldn't scan at all and if user will choose proximity pairing mode - it should scan for every peripheral with specified name.

I have implemented it basing on ble_app_hrs_c example and after connection to peripheral device, peer manager is returning an error NRF_ERROR_NOT_FOUND when callingpm_whitelist_set function. In function whitelist_load() from ble_app_hrs_c example it looks following:

static void whitelist_load()
{
    ret_code_t   ret;
    pm_peer_id_t peers[8];
    uint32_t     peer_cnt;

    memset(peers, PM_PEER_ID_INVALID, sizeof(peers));
    peer_cnt = (sizeof(peers) / sizeof(pm_peer_id_t));

    // Load all peers from flash and whitelist them.
    peer_list_get(peers, &peer_cnt);

    /* HERE in my application I am checking detected peers list.
       peer number prints out as 1 and peer list contain one
       peer with index 0 */

    NRF_LOG_INFO("Get peer list");
    ret = pm_whitelist_set(peers, peer_cnt);
    /* HERE error is returned */
    APP_ERROR_CHECK(ret);

    NRF_LOG_INFO("Whitelist done!");
    // Setup the device identies list.
    // Some SoftDevices do not support this feature.
    ret = pm_device_identities_list_set(peers, peer_cnt);
    if (ret != NRF_ERROR_NOT_SUPPORTED)
    {
        APP_ERROR_CHECK(ret);
    }
}

So there is one peer and even pm_peer_count() function returns 1 but for some reason pm_whitelist_set() function has problem in finding it.

Could you help me in this case or provide some simple example of application where Central is switching between those 3 states (No scanning, scanning with whitelist, normal scan with filters)

Best regards

[Amanda Hsieh]

Hi, 

The 133 (0x85) is BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, and the 137 (0x89) is BLE_GAP_SEC_STATUS_REPEATED_ATTEMPTS. It seems that the peer or the central doesn't support the pairing.  

Could you test using ble_app_hrs as peripheral and capture a sniffer trace? so we know what exactly happens with the sniffer log. 

-Amanda H.

[Karol D]

This issue of ble_app_hrs_c example is probably connected with old keys saved on peripheral device. I think so because it works only before 1st connection after flashing. When first bonding procedure occur then peripheral store the keys and reply for next bonding requests with BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP

[Karol D]

And about main issue I think I solved it (since it seems to work now)

There was a problem that I wanted to add a peer to whitelist just after bonding procedure is finished. Now, I think its not possible and the only moment when I can do that is after NRF_BLE_SCAN_EVT_WHITELIST_REQUEST event like in the ble_app_hrs_c example.

Then another problem with code 0x3204 occurred. And it turned out that advertising have to be stopped before  pm_device_identities_list_set function can be called.

After those two fixes it seem to work. I think it would be nice to consider to add some more documentation to ble_app_hrs_c example in order to clarify such important aspects

Best regards

[Amanda Hsieh]

Great to hear success and feedback. I will report to the internal. 

Cheers,

Amanda