Central adds peripheral to the whitelist, but won't reconnect

RE: Central adds peripheral to the whitelist, but won't reconnect

Hung Bui — Wed, 16 Aug 2017 07:44:31 GMT

@Nick: Please check , if both addr_cnt == 0 && irk_cnt == 0 , whitelist will not be used at least that what in the code you posted. Could you please double check ?

You can check the IRK on the central side. Try to connect with 2 peripheral, one by one. And see if the IRK matched for each device when you repeat the test.

Note that you need to make sure the address is resolvable random address, otherwise the IRK is not relevant (if they are static addresses then the address should be used for whitelisting).

RE: Central adds peripheral to the whitelist, but won't reconnect

Nick Bentzen — Tue, 15 Aug 2017 12:27:51 GMT

Hi Hung, reconnect() just resets/initializes some non-Bluetooth related stuff, nothing to do with the softdevice or the connection.

When I have tested my code I erase the bonds on each device using a switch like in the examples, then test with both devices having erased their bonds but erase_bonds = 0.

If m_whitelist_disabled = false in my central device, but it has no bonding information, it will connect and add the peripheral to peer manager, but when I restart (power cycle) the central device, it will not reconnect to that same peripheral. Where do I check to see if the IRKs are consistent? On the peripheral? On the central?

RE: Central adds peripheral to the whitelist, but won't reconnect

Hung Bui — Tue, 15 Aug 2017 07:42:04 GMT

Hi Nick,

Seems that the IRK is exchanged. Could you check if the IRK returned match with each of the central you connect ?

What is in "reconnect() " ?

Could you check if erase_bonds=1 when peer_manager_init() is called ? In our example we have a button to erase bond (and therefore whitelist), make sure it's not pressed by default.

One thing I don't understand, in your question you said if you don't use whitelist, everything works fine. If you use whitelist you can't scan and connect. But then your whitelist is empty as you mentioned in your comment, so how could it make a different ?

RE: Central adds peripheral to the whitelist, but won't reconnect

Nick Bentzen — Mon, 14 Aug 2017 16:22:47 GMT

postimg.org/.../

I'll work on getting a dev kit set up as a sniffer.

These are some relevant functions from the peripheral device.

https://pastebin.com/CMkmnxnE

RE: Central adds peripheral to the whitelist, but won't reconnect

Hung Bui — Mon, 14 Aug 2017 15:46:55 GMT

I'm sorry Nick. I mean peer_data. You need to step into pdb_write_buf_store() and check what peer_data is extract from the database using write_buffer_record_find(). What inside peer_data can tell if the IRK/address is there.

Can you capture a sniffer trace ?

I suspect the peer device may not support bonding, just pairing.

RE: Central adds peripheral to the whitelist, but won't reconnect

Nick Bentzen — Mon, 14 Aug 2017 13:59:03 GMT

I'm not sure what you mean by that? I thought peer_id was just an integer, there's nothing in it?

RE: Central adds peripheral to the whitelist, but won't reconnect

Hung Bui — Mon, 14 Aug 2017 13:16:28 GMT

Could you check what in the peer_id ? It's pretty strange to see everything is 8 if it's not 0

RE: Central adds peripheral to the whitelist, but won't reconnect

Nick Bentzen — Mon, 14 Aug 2017 13:04:51 GMT

static void whitelist_load() { ret_code_t ret; pm_peer_id_t peers[BLE_GAP_WHITELIST_ADDR_MAX_COUNT]; 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);
m_whitelist_peers = peer_cnt;
ret = pm_whitelist_set(peers, peer_cnt);
APP_ERROR_CHECK(ret);

 //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);
}
}

Here are the results of putting a breakpoint on pdb_write_buf_store():

s29.postimg.org/.../debug.png

RE: Central adds peripheral to the whitelist, but won't reconnect

Hung Bui — Mon, 14 Aug 2017 11:24:23 GMT

What do you have inside whitelist_load() ?

Also we need to see if there is a bonding in your connection. Could you capture a sniffer trace ?

If you don't could you add a break point inside auth_status_success_process() and check if the peer_id is stored (pdb_write_buf_store() called) ? and what inside peer_id ?

RE: Central adds peripheral to the whitelist, but won't reconnect

Nick Bentzen — Fri, 11 Aug 2017 17:49:14 GMT

Hi Hung Bui,

I noticed that when the whitelist loads, the IRK and address are blank. So peer manager is saving a peer, but not properly recovering its information after a power cycle?

Also I call sd_ble_gap_connect() just like in the nus_c example.

devzone.nordicsemi.com/.../

Could this be related?

RE: Central adds peripheral to the whitelist, but won't reconnect

Hung Bui — Fri, 11 Aug 2017 15:18:15 GMT

Hi Nick,

sd_ble_gap_scan_start() won't do connection. It only scan for advertising packet. If you want to connect you use sd_ble_gap_connect(). I assume here you don't receive advertising packet that should have whitelisted address ?

When you debug, what do you see in the whitelist ? They are IRK or static address ? Would they match with the IRK/address you get when you bond to the device?

You may want to capture a sniffer trace to see what happens.