20 peers on Peer Manager but 8 peers on SoftDevice

[Basprog]

Peer Manager in recent SDKs supports up to 20 peers but SoftDevice functions like sd_ble_gap_whitelist_set() and sd_ble_gap_device_identities_set() are able to handle up to 8 addresses only. How to whitelist and get resolved peers #9-20?

[Einar Thorsrud]

Hi,

Peer Manager in recent SDKs supports up to 20 peers but SoftDevice functions like sd_ble_gap_whitelist_set() and sd_ble_gap_device_identities_set() do able to handle up to 8 addresses only

The limitation of 8 MAC address and IRK's is due to a HW limitation, as filtering happens in the RADIO peripheral itself. The peer manager supports an arbitrary number of bonds, only limited by the available flash (this can be more than 20). The number 20 probably comes from the maximum number of simultaneous connections, which is 20 for recent SoftDevice versions.

How to whitelist and get resolved peers #9-20?

 It is not possible. However, there are a few alternative approaches that might be used:

1. You could allow any device to connect, and then simply disconnect if the device is not one of the devices that are allowed to connect (a conceptual whitelist). There is a possibility for a form of denial of service attack here, where attackers could constantly try to connect, but it is probably not a real problem in most applications.
2. You could alternate so that you only advertise with a whitelist of 8 peers for some time, then advertise to a different set of 8 peers etc. before returning back to the initial 8 peers. And so on. This will of course increase the time it takes for a peer to connect if it is not one of the currently accepted peers.

[Basprog]

Dear Einar, let me dispute with you.

Einar Thorsrud said:

The limitation of 8 MAC address and IRK's is due to a HW limitation

RADIO can in truth whitelist up to 8 public/static addresses. While AAR is able to handle up to 16 IRKs (actually up to 15, one slot is occupied by device own IRK) – SoftDevice does simply not fully use it up to my mind.

Einar Thorsrud said:

You could allow any device to connect, and then simply disconnect if the device is not one of the devices that are allowed to connect

I understand this as a suggestion of software whitelisting. OK, let's assume I'll follow this way, particularly: no calls of sd_ble_gap_whitelist_set() nor sd_ble_gap_device_identities_set(), on BLE_GAP_EVT_ADV_REPORT iterate over all bonded peers (public/static addresses by 6-byte comparison, resolvable addresses by call of sd_ecb_block_encrypt()) then, if any matched, call of sd_ble_gap_connect().

If I'm right with solution on your suggestion, let's get a closer look into im_ble_evt_handler() which will handle BLE_GAP_EVT_CONNECTED: it does the same (iterates over all bonded peers the same way as above) just to find matched peer_id. So my supplementary question is following: why did Nordic limit access to the whole 16 slots of AAR resulted in double semi-software iteration in case of more than 8 bonds?

For the semi-software I mean change endianness of a key and clear/cipher texts in software then call of sd_ecb_block_encrypt() for the each bond while we have AAR which does all the job in hardware for up to 16 keys.

Einar Thorsrud said:

The peer manager supports an arbitrary number of bonds, only limited by the available flash (this can be more than 20). The number 20 probably comes from the maximum number of simultaneous connections

The source of probable cross-mixing of maximum numbers of bonds and connections is following declaration at id_manager.c:

#define IM_MAX_CONN_HANDLES             (20)

static im_connection_t m_connections[IM_MAX_CONN_HANDLES];

[Einar Thorsrud]

Hi,

You are right that the AAR support up to 16 IRKs. The old S110 SoftDevice for the nRF51 series had a limit of 8 IRKs, due to some related SW processing in the SoftDevice, and that limitation has been kept in the nRF52 SoftDevices. I have not been able to confirm whether it the reason for not supporting more than 8 is valid for the nRF52 as well, but I have created an internal feature request so that it can be considered and potentially added in a future release. You should not expect that to happen any time soon, though.

[Basprog]

Am I also right that software whitelisting by above mentioned way is the only solution in case of more than 8 bonds?

If yes, is there any way for the application to report a matched peer_id to Peer Manager to avoid reiteration over all bonds?

[Einar Thorsrud]

Basprog said:

Am I also right that software whitelisting by above mentioned way is the only solution in case of more than 8 bonds?

Yes, doing it in SW is the only option of you need to handle a whitelist of more than 8 IRKs.

Basprog said:

If yes, is the any way for the application to report a matched peer_id to Peer Manager to avoid reiteration over all bonds?

I have not been able to look into how you can do that, but I would think it should be possible with some adjustments to the peer manager. Unfortunately I will not be able to look into it in more detail until next week, due to Easter.