20 peers on Peer Manager but 8 peers on SoftDevice

RE: 20 peers on Peer Manager but 8 peers on SoftDevice

Basprog — Wed, 20 Nov 2019 11:21:32 GMT

Hi Einar, is there any news for internal feature request you've created more than a half year ago and three desire points mentioned above this post?

RE: 20 peers on Peer Manager but 8 peers on SoftDevice

Basprog — Thu, 18 Apr 2019 12:40:15 GMT

Got it. Thank you. So I'm in waiting for Nordic to expand usability as following:

sd_ble_gap_whitelist_set() and sd_ble_gap_device_identities_set() take up to 16 addresses and keys;
SoftDevice sets addr_id_peer = 1 if there was a match to any of 16 IRKs;
Peer Manager uses AAR.STATUS to check which one of 16 IRKs matched to avoid iteration over them by calling sd_ecb_block_encrypt().

RE: 20 peers on Peer Manager but 8 peers on SoftDevice

Einar Thorsrud — Wed, 17 Apr 2019 12:47:14 GMT

[quote user="Baspro"]Am I also right that software whitelisting by above mentioned way is the only solution in case of more than 8 bonds?[/quote]

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

[quote user="Baspro"]If yes, is the any way for the application to report a matched peer_id to Peer Manager to avoid reiteration over all bonds?[/quote]

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.

RE: 20 peers on Peer Manager but 8 peers on SoftDevice

Basprog — Wed, 17 Apr 2019 11:32:32 GMT

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?

RE: 20 peers on Peer Manager but 8 peers on SoftDevice

Einar Thorsrud — Wed, 17 Apr 2019 10:42:45 GMT

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.

RE: 20 peers on Peer Manager but 8 peers on SoftDevice

Basprog — Tue, 16 Apr 2019 14:31:17 GMT

Dear Einar, let me dispute with you.

[quote userid="7377" url="~/f/nordic-q-a/46218/20-peers-on-peer-manager-but-8-peers-on-softdevice/182367"]The limitation of 8 MAC address and IRK's is due to a HW limitation[/quote]

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.

[quote userid="7377" url="~/f/nordic-q-a/46218/20-peers-on-peer-manager-but-8-peers-on-softdevice/182367"]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[/quote]

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.

[quote userid="7377" url="~/f/nordic-q-a/46218/20-peers-on-peer-manager-but-8-peers-on-softdevice/182367"]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[/quote]

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];

RE: 20 peers on Peer Manager but 8 peers on SoftDevice

Einar Thorsrud — Tue, 16 Apr 2019 11:54:05 GMT

Hi,

[quote user=""]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[/quote]

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.

[quote user=""]How to whitelist and get resolved peers #9-20?[/quote]

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

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.
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.