Softdevice / Whitelist Issues

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
Parents
  • 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?

  • There are a few peripheral examples that use whitelisting. In that case, they use whitelisting after having established a bond, and the whitelist is populated with bonded device(s). See for instance the implementation in examples\ble_peripheral\ble_app_hids_mouse\main.c.

    The most important thing to note is that ble_adv_whitelist_enabled is set to true in the configuration struct that is passed to ble_advertising_init(), and the handling of the BLE_ADV_EVT_WHITELIST_REQUEST event. There, the whitelist is provided to the SoftDevice upon request. Here it comes from the peer manager, but you could also build a list of addresses for non-bonded device(s) if that fits your use case better.

    SteveHx said:
    If possible I would like to also allow connections to nRF Connect running on either an Android or an iPhone.

    To do so, if that should be any device, and not some you have paired with before, you would need to exchange the IRK (as phones use a resolvable random address for privacy reasons), which is done through pairing. So you would typically need a way to temporarily disable whitelisting, like is commonly done on HID devices with a special button. After that, you could include also the phone in the whitelist (again, just as HID devices normally do, including the mouse example - search for ble_advertising_restart_without_whitelist()).

Reply
  • There are a few peripheral examples that use whitelisting. In that case, they use whitelisting after having established a bond, and the whitelist is populated with bonded device(s). See for instance the implementation in examples\ble_peripheral\ble_app_hids_mouse\main.c.

    The most important thing to note is that ble_adv_whitelist_enabled is set to true in the configuration struct that is passed to ble_advertising_init(), and the handling of the BLE_ADV_EVT_WHITELIST_REQUEST event. There, the whitelist is provided to the SoftDevice upon request. Here it comes from the peer manager, but you could also build a list of addresses for non-bonded device(s) if that fits your use case better.

    SteveHx said:
    If possible I would like to also allow connections to nRF Connect running on either an Android or an iPhone.

    To do so, if that should be any device, and not some you have paired with before, you would need to exchange the IRK (as phones use a resolvable random address for privacy reasons), which is done through pairing. So you would typically need a way to temporarily disable whitelisting, like is commonly done on HID devices with a special button. After that, you could include also the phone in the whitelist (again, just as HID devices normally do, including the mouse example - search for ble_advertising_restart_without_whitelist()).

Children
No Data
Related