Softdevice / Whitelist Issues

RE: Softdevice / Whitelist Issues

Jimmywong2003 — Tue, 11 Jan 2022 00:52:23 GMT

Hi,

You can find some examples which I did on the whitelist at central and peripheral role.

Both examples are not using bonding. Just the MAC address on whitelist table.

Peripheral Role

jimmywongiot.com/.../

Central Role

jimmywongiot.com/.../

Jimmy

RE: Softdevice / Whitelist Issues

SteveHx — Mon, 10 Jan 2022 23:43:49 GMT

I'm now back from my trip to the customer site and getting caught up on emails. It appears the problem was repeated collisions due to the amount of traffic and update interval. I fixed it for the upcoming demo by extending the update interval and randomizing it so any two units don't repeatedly collide with one another. Thank you very much for all the help, and the reminder that I need to download and learn about the new nRF Connect SDK.

RE: Softdevice / Whitelist Issues

Einar Thorsrud — Fri, 07 Jan 2022 11:33:37 GMT

Hi Steve,

I see now that you have references to Zephyr (so nRF Connect SDK), but earlier in this thread you have made references to SoftDevice and nRF5 SDK Code. Do you use the nRF5 SDK for the peripherals and the nRF Connect SDK for the central? That in itself is no problem, I just want to get a better understanding. With "Multi NUS", are you referring to this project from this blog post? Is this your central?

[quote user="SteveHx"]

I have discovered that the 52840 multi-NUS randomly throws an error and reboots:

ASSERTION FAIL [conn] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/gatt.c:4437

invalid parameters

[/quote]

Which nRF Connect SDK version are you using? based on the assert line number I am guessing 1.6.x, so I will assume that for now.

The assert in zephyr/subsys/bluetooth/host/gatt.c:4437 is checking that the first parameter (struct bt_conn *conn) is not NULL, so as you get this assert it means you passed NULL / 0 to the call to bt_gatt_subscribe() for some reason. You need to review and/or debug your application to se how this can happen.

There is clearly a bug you see here, but there could also be other issues. As you use as may as 15-20 peripheral connected to a single central, that means it must handle and find time to a lot of concurrent connections (in addition to scanning). Which connection parameters do you use? That is essential here with so many devices. You typically need long connection intervals and short event lengths to get this working. You probably also want a long supervision timeout.

[quote user="SteveHx"]We also need a way, either by modifying the source code, or thru the USB link, to cause multi-NUS to periodically rescan for units that may have been missed.[/quote]

Looking at the multi NUS code from the blog, I see that it generally always scans except for during service discovery, so you should not need to explicitly start it. If you want to, you can add code for that, but there is no code in the example I am looking at that lets you control this from USB or UART, so you must add that (and decide how you want it to work).

Einar

RE: Softdevice / Whitelist Issues

SteveHx — Thu, 06 Jan 2022 21:57:54 GMT

I am now at the client site (long day so far). Still having problems maintaining reliable connections between multi-NUS on the 52840 DK board, and about 15-20 user application devices running 52832 with a custom application derived from the UART sample app. I have discovered that the 52840 multi-NUS randomly throws an error and reboots:

ASSERTION FAIL [conn] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/gatt.c:4437

invalid parameters

The multi-NUS then reboots, but of course takes time to reestablish all the connections.

We also need a way, either by modifying the source code, or thru the USB link, to cause multi-NUS to periodically rescan for units that may have been missed.

Any suggestions?

Steve Hendrix

RE: Softdevice / Whitelist Issues

Einar Thorsrud — Thu, 06 Jan 2022 07:50:29 GMT

Hi Steve,

[quote user="SteveHx"] We are still having a problem with peripherals disappearing from multi-NUS, and struggling to find any commonality to the disappearances. At this time the evidence is starting to suggest that the problem is not the Peripheral being grabbed by a different Central[/quote]

I see. What data do you have of what is actually happening? Do you have logging on the peripheral side? If you for instance log whenever a connection is established including the address of the peer and when connections are closed, that should be quite useful. Perhaps something completely different is happening, and if so adding a bit of logging here and there might show some unexpected things.

[quote user="SteveHx"]I presumed I could changed those numbers to 2 to allow two simultaneous connections. That leads to another of those mysterious breakpoints with no information as to what happened. Based on past experience, I tried increasing the RAM available to the softdevice by 512 bytes. No joy; those two parameters must be set to 1. How are those to be used?[/quote]

You need to increase the RAM reserved for the SoftDevice (so use a higher application RAM start address and lower size). But there is nothing in the description of your application that indicate that you need to support more concurrent connections on the peripherals? Also, for this to be useful (if it was relevant), you would have to adjust your application to actually handle multiple connections.

[quote user="SteveHx"]2) In main.c, cp_init.disconnect_on_fail is set to false in the provided example. At some time in the past, I experimentally changed it to true and left it that way. Could that be a cause of failures to connect or reconnect?[/quote]

That could be. I suggest you add logging to see what the disconnect reason is. If the connection parameter module disconnects because of this you should get the BLE_HCI_CONN_INTERVAL_UNACCEPTABLE (0x3B) disconnect reason.

[quote user="SteveHx"]

3) Near the top of main.c are several parameters defined that I don't understand, that may or may not be relevant to my immediate problem.

MIN_CONN_INTERVAL

MAX_CONN_INTERVAL

SLAVE_LATENCY

CONN_SUP_TIMEOUT

I can't find any concise explanation of these and how they may or may not be relevant to my immediate problem.

[/quote]

These are the connection parameters, which are the most essential parameters of a Bluetooth connection. See this old post. As you control both the central and peripheral side here, you should simply configure the same connection parameters on both sides and this will just work. What connection parameters you should use are application specific (which latency, throughput, timeout fits your specific application?). As you have multiple connections on the central side you should not be too aggressive here, as the central needs to be able to schedule and fit all it's connections.

[quote user="SteveHx"]5) Any other suggestions for more reliable connections / reconnections?[/quote]

I understand you are short on time, but I would say that you need to first debug and analyze to understand what actually happens. Once that is clear, fixing the problem should be much easier.

RE: Softdevice / Whitelist Issues

hmolesworth — Wed, 05 Jan 2022 23:15:49 GMT

Have to mention the obvious issue having been caught by this before, in case you didn't consider it; what are these two values set at?

#define APP_ADV_INTERVAL  (244)  /**< The advertising interval (in units of 0.625 ms. This value corresponds to 152.5 ms). */
#define APP_ADV_DURATION  3000   /**< The advertising duration (30 seconds) in units of 10 milliseconds. 0 == forever */

In a BLE-noisy (well, 2.4GHz noisy) environment, a slow advertising interval of (say) 1 second is never going to successfully connect and if a default stop-after-trying 30 second timer is active (Nordic default) the peripheral will simply disappear after 30 seconds, or whatever that timer is set to. Best to advertise until end-of-time (== battery exhausted) and more frequently than once-per-second..

Edit: if you are using Zephyr the definitions above will be set differently, no idea how; these are for nRF52 SDK usage

RE: Softdevice / Whitelist Issues

SteveHx — Wed, 05 Jan 2022 21:35:43 GMT

I really need to explore all the info you gave me on whitelisting more thoroughly, but at the moment I'm shifting to panic mode as I am to fly to NJ tomorrow morning with my equipment and able to set up the demo for my client. We are still having a problem with peripherals disappearing from multi-NUS, and struggling to find any commonality to the disappearances. At this time the evidence is starting to suggest that the problem is not the Peripheral being grabbed by a different Central, so whitelisting isn't going to help that. But I've been poking around and trying to better understand the BLE stack, and came up with a number of questions:

1) You indicated that S112 should be able to handle 4 simultaneous connections. Looking at these two lines from sdk_config.h

#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1

#define NRF_SDH_BLE_TOTAL_LINK_COUNT 1

I presumed I could changed those numbers to 2 to allow two simultaneous connections. That leads to another of those mysterious breakpoints with no information as to what happened. Based on past experience, I tried increasing the RAM available to the softdevice by 512 bytes. No joy; those two parameters must be set to 1. How are those to be used?

2) In main.c, cp_init.disconnect_on_fail is set to false in the provided example. At some time in the past, I experimentally changed it to true and left it that way. Could that be a cause of failures to connect or reconnect?

3) Near the top of main.c are several parameters defined that I don't understand, that may or may not be relevant to my immediate problem.

MIN_CONN_INTERVAL

MAX_CONN_INTERVAL

SLAVE_LATENCY

CONN_SUP_TIMEOUT

I can't find any concise explanation of these and how they may or may not be relevant to my immediate problem.

4) My application has a basic "heartbeat" at 5 seconds, at which interval it checks for incoming commands from the multi-NUS, and sends out a status report of a couple dozen ASCII characters. Could this interval interact in bad ways with anything in the BLE stack?

5) Any other suggestions for more reliable connections / reconnections?

Help! I'm going to see my client in the morning.

Steve Hendrix

RE: Softdevice / Whitelist Issues

Einar Thorsrud — Wed, 05 Jan 2022 13:32:37 GMT

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.

[quote user="SteveHx"]If possible I would like to also allow connections to nRF Connect running on either an Android or an iPhone.[/quote]

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

RE: Softdevice / Whitelist Issues

SteveHx — Wed, 05 Jan 2022 12:39:30 GMT

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?

RE: Softdevice / Whitelist Issues

Einar Thorsrud — Wed, 05 Jan 2022 09:53:27 GMT

Hi,

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

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.

[quote user="SteveHx"]Is the whitelist the wrong mechanism here?[/quote]

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.

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

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.

RE: Softdevice / Whitelist Issues

SteveHx — Tue, 04 Jan 2022 15:17:46 GMT

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?

RE: Softdevice / Whitelist Issues

SteveHx — Tue, 04 Jan 2022 13:15:06 GMT

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.

RE: Softdevice / Whitelist Issues

Einar Thorsrud — Tue, 04 Jan 2022 12:53:24 GMT

Hi,

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

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.

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

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.