Whitelist set but not automatically restarted

[Gueston]

Hi,

When I bond with a central to my device, the peer gets added to the whitelist. But I want my device (peripheral), to automatically start advertising in whitelist after the peer get's bonded, but it only does this when I restart the device.

I also make use of multipeers which can be connected at same time, perhaps that's the problem?

How can I force a restart of the advertising in whitelist whithout a reset of the device?

[Gueston]

Hi, just a bump because it's been almost 2 weeks and still didn't get a reply.

What I also noticed is, that apart from resetting, it also starts to advertise in whitelisting after bonding if I first disconnect and then reconnect,

But I want it to go to whitelist advertising immediately after a bond, without reset or reconnect. But I suspect the fact that I continue advertising when connected to a peer is part of the problem, because I want to be connected to multiple peers. So where can I some sort of reset the advertising in the peer manager? I am using the peer_manager_handler.c by the way for the event handling of peer manager.

[tesc]

Hi,

I am sorry for the long wait.

Are you using nRF5 SDK, or nRF Connect SDK?

What example have you based the solution on? There are some differences between the examples, how things are set up, which affects how whitelists, advertising, number of connections work.

Regards,
Terje

[Gueston]

I use nRF5 SDK. I used the multipeer example together with the HID Keyboard, because I wanted a multipeer with bonding capabilities.

[Gueston]

Hi, any updates? This ticket is already 3 weeks old. Do you perhaps need the source code to analyse it?

[tesc]

Hi,

I realize that this has been left unanswered for way too long, but answering in case you still see the issue and/or if others see the same in the future.

The key to controlling whitelist usage in nRF5 SDK is through the advertising module. If you look at e.g. the HID keyboard example, the advertising settings are stored in m_advertising in main.c, and that structure is what at all times decides the current behavior of advertising. It is sent in to calls to the advertising module API.

When initialized through ble_advertising_init() with a configuration to use whitelist (init.config.ble_adv_whitelist_enabled = true), it will use whitelist except for in a couple of situations:

• If there are no peers for the whitelist.
• If advertising without whitelist is explicitly initiated through ble_advertising_restart_without_whitelist().

Places to look when not getting a whitelist:

• Advertising module: The event handler for the advertising module (default name on_adv_event() e.g. in the HID keyboard example). It must handle the BLE_ADV_EVT_WHITELIST_REQUEST by returning a whitelist through ble_advertising_whitelist_reply().
• Peer Manager: The policy for adding devices to the whitelist. Addresses are added to the whitelist on the PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event from peer manager (default name pm_evt_handler() e.g. in the HID keyboard example.) It is added by a call to whitelist_set(), and the argument to that call describes what kind of addresses to add to the whitelist. If the newly added peer has an address of a type that is not to be stored in the whitelist, you will end up with an empty whitelist, which again can make the advertising module advertise without whitelist.
• See if advertising is started by ble_advertising_restart_without_whitelist(). In some situations this is wanted, at least in most cases you need some way to recover and allow for new devices to connect for the situations where the known (whitelisted) devices get lost or forget the bond. But this may also be the way advertising gets started in the situation where you want whitelist but do not get it.

Regards,
Terje