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

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