Softdevice / Whitelist Issues

[SteveHx]

We are attempting to deploy a system consisting of one nRF52840 devkit running the multi-NUS example app, and over a dozen custom boards based on the nRF52832. It all works fine at my facility, which is very much RF-quiet. When attempting to bring up the system at the customer site, we appear to be getting the custom units captured by other BLE central devices. Attempting to track those down, but only partially successful. The custom board is using the 112 softdevice. What is the difference between 112 and 132? I have a vague recollection that with 132 we could be connected by multiple devices whereas 112 was restricted to a single connection at a time. If that is the case, I want to try to change to the 132 device. Surely there is a straightforward way within SES to do that?

I am also looking for a way to have our device only allow connections from our central device. I remember seeing something like that, though I really don't want to go the full Bonding route (but may have to).

Suggestions very welcome! The customer is in a bit of a panic because we're setting up for a big demonstration to customer's customer this Friday.

Steve Hendrix

[Einar Thorsrud]

Hi,

What is the difference between 112 and 132? I have a vague recollection that with 132 we could be connected by multiple devices whereas 112 was restricted to a single connection at a time

There are a number of differences. You can compare the SoftDevice specifications of both to see all. Note that also S112 supports multiple concurrent connections, but it is limited to 4.

If that is the case, I want to try to change to the 132 device. Surely there is a straightforward way within SES to do that?

I do not know the details of your application, so I may be wrong, but based on what you wrote I do not see why you want to change SoftDevice. That said, SoftDevices of the same version number is API compatible, so migrating from for instance S112 version 7.2.0 to S132 7.2.0 is quite straight-forward. Primarily, you need to:

• Change the application start address to match the new SoftDevice size.
  
  • You may also need to increase the application RAM start address (see Adjustment of RAM and Flash memory).
• Change application include path to use the header files for the new SoftDevice
• Change preprocessor defines that indicate SoftDevice type (so change S112 to S132)
• Flash the new SoftDevice hex intead of the old (to get this automatically done by SES, adjust the additional load file here:

Based on the problem description, and assuming you only want to allow connections from a single central it seems like whitelisting is more sensible in this case. If for instance you pair these devices in production, then you could whitelist only the intended central, and only that would be able to connect. Exactly if and how this can and should be done depends on what fits your specific use case.

[SteveHx]

Thank you for the detailed and patient explanations. I agree with your conclusion that whitelisting is the way to go for this app. Can you please point me to the documentation on how to do whitelisting? I find that searching the Nordic documentation is a very deep rabbit hole, with the information all there but quite scattered.

[SteveHx]

After some further reading, I'm seeing that my understanding of the whitelist may be inverted. If I'm reading correctly now, the whitelist is a list in the Central end, that defines what Peripheral units can connect. That doesn't address our present issue. We have over a dozen Peripheral units that want to be connected to the multi-NUS Central app running on a 52840 DK. We appear to be having a problem in that our Peripheral units are advertising and then are grabbed by a nearby iPhone etc., at which point they cease advertising and thus we are unable to find them from the multi-NUS app. Is the whitelist the wrong mechanism here? Is there some other mechanism I should be looking at, to prevent the Peripheral units from accepting a connection for other than our own units? I could picture a mechanism by which our Peripheral expects to immediately receive some special command upon connecting, and if that command is not forthcoming, immediately disconnects and resumes advertising. Even that seems a bit kludgy. What am I missing here?

[Einar Thorsrud]

Hi,

SteveHx said:

After some further reading, I'm seeing that my understanding of the whitelist may be inverted. If I'm reading correctly now, the whitelist is a list in the Central end, that defines what Peripheral units can connect. That doesn't address our present issue.

That is not the case. The whitelist concept is available both for the central and peripheral roles. If a peripheral use whitelisting (which is what is relevant here), connections from a non-whitelisted central are ignored by the Bluetooth stack, and it is not able to connect.

SteveHx said:

Is the whitelist the wrong mechanism here?

Whitelisting is the normal way to solve this problem, though I do not have a full overview of your use case so there may be factors that makes another approach more sensible.

SteveHx said:

I could picture a mechanism by which our Peripheral expects to immediately receive some special command upon connecting, and if that command is not forthcoming, immediately disconnects and resumes advertising.

You can do that, but it would be more complex and involve more processing than if you use whitelisting (where the connection request is ignored and so as little processing as possible is used).

I am not sure about how you do things in practice. Will you pair up the central and peripherals in production? If so, you could either pair the devices in the factory, or simply write the BLE address of the central to a specific register/memory location in the peripherals, and they could whitelist only that address. For the latter, se this post.

If you need to pair up the devices in the field, then you probably still want to use whitelisting, but also have a method to pair them, and whitelist  only thee paired device(s). To prevent other devices from pairing you could use MITM protection with a passkey or similar. If these devices do not have keyboard or display MITM protection mechanisms are not supported by the standard, but you could use a hard coded pass key for instance to prevent other devices from pairing. Note that a hard coded passkey does not provide any security, so an attacker could circumvent it, but it would prevent a non-malicious device near by from accidentally connecting and pairing.

[SteveHx]

Okay, whitelisting it is. but I can't find any reference as to how to enable whitelisting. I expected to find a flag of some sort in sdk_config.h; no joy. A global search of the project (which was based on the ble_peripheral uart example) turns up a dozen or so hits but nothing that shows how to set it up. For this specific project (I can generalize later) I need to allow connecting only to the multi-NUS example running on the Nordic 52840 devkit. If possible I would like to also allow connections to nRF Connect running on either an Android or an iPhone. Can you point me to a place to start?