[nRF Connect SDK] Make ble connectable only for multiple paired(bonded) devices

[Tim Hwang]

Target nRF52832(nrf52dk_nrf52832)
SDK NCS v1.9.1

Base source
1. C:\Users\user\ncs\v1.9.1\nrf\samples\bluetooth\peripheral_hids_keyboard
2. C:\Users\user\ncs\v1.9.1\nrf\samples\bluetooth\peripheral_uart

My project require two mode(HID and NUS).
I made new project that support two mode.(User can select mode, and each mode will begin at boot time).

-----------------------------------------------------------------------------------------------------
My project used BT classic. So it can be acceptable for incoming connection regarding paired(bonded) device without discoverable option.
BLE protocol as peripheral role does not allow to accept incoming connection without advertise.
My question is following scenario is possible.

1. Make bonding with serveral other devices(Android, iOS or Windows). (CONFIG_BT_MAX_PAIRED=4)
2. Reboot BLE device(nordic)
3. BLE begin to advertise only for paired devices. (I found we could add paired list into advertise information)
4. Keep advertise until one of paired devices try to connect.
5. Accept incoming connection.
6. If BLE disconnected, BLE begin to advertise again. (Only for paired)
7. If BLE want to pair another device, BLE stop advertise and begin to advertise without paired list.
8. Make pairing for new device.

My customer use several our BLE product at the same time, so please review if my scenario is possible.
Thanks.

[Edvin]

Hello,

Yes, this is possible (and the common way to do things). 

I have not looked that much into this in NCS before, but it looks like the ble_adv_start() function found in NCS(v1.9.1)\nrf\subsys\caf\modules\ble_adv.c (caf - common application framework are just samples on how to use particular modules) is one way to do this. Look at how it uses ble_adv_start_directed() and ble_adv_start_undirected().

I don't see a way to temporary disable the whitelist, so you would need to clear the list if you want to advertise without a whitelist, and store the addresses and reapply them later.

I know that this is counterintuitive, but I would be surprised if it is not possible to make the bond manager handle this for you. I will have to look into it a bit more (but I wanted to answer you before too much time passed).

The list that you describe is very easy to do in the nRF5 SDK, so I would be surprised if there aren't any libraries that does this in NCS (I am just not aware of them yet). I would look into the peripheral_uart sample, and look at the settings module (BT_SETTINGS is the module handling bonding).

BR,

Edvin

[Tim Hwang]

Thanks for updating. I will test ble_adv_start_directed() then reply you.

[Update]

1. ble_adv_start_directed()
To use ble_adv_start_directed() in ble_adv.c, I have to call ble_adv_start() in ble_adv.c.
My base source(peripheral_hids_keyboard, peripheral_uart) never call ble_adv_start().
I cannot call ble_adv_start() in app level directly.

2. Similary peer list sample
"ncs/v1.9.1/nrf/samples/bluetooth/peripheral_nfc_pairing"
Above sample shows how I add peer list into adv param.
It works if peer is working, but if peer is turned off, That sample fail to connect and never start advertise again.
(I received connected but actually disconnected.

If I force to advertise again, BLE connected -> disconnect -> advertise -> connected -> ...)

C:\Users\user\ncs\v1.9.1\nrf\samples\bluetooth\peripheral_nfc_pairing\src\main.c

static void advertising_continue(void)
{
struct bt_le_adv_param adv_param;

bt_addr_le_t addr;

if (!k_msgq_get(&bonds_queue, &addr, K_NO_WAIT)) {
char addr_buf[BT_ADDR_LE_STR_LEN];

adv_param = *BT_LE_ADV_CONN_DIR(&addr);
adv_param.options |= BT_LE_ADV_OPT_DIR_ADDR_RPA;

int err = bt_le_adv_start(&adv_param, NULL, 0, NULL, 0);

if (err) {
printk("Directed advertising failed to start\n");
return;
}

bt_addr_le_to_str(&addr, addr_buf, BT_ADDR_LE_STR_LEN);
printk("Direct advertising to %s started\n", addr_buf);
}
...
}

So plesae let me have any sample. and tell me if my scenario is possible.

[Edvin]

Tim Hwang said:

From this test, I would say BLE cannot advertise only for paired (bonded) devices only, right?

What do you mean by this?

Advertisements are never encrypted, so it is not possible to advertise so that certain devices "doesn't see it". However, most devices will not display whitelisted/directed advertisements to the user if they are not bonded with the device. However, if you used nRF Connect for Android to connect to this device, it will show you all advertising devices. 

Did you see your device in the phone's bluetooth settings?

BR,

Edvin

[Tim Hwang]

However, most devices will not display whitelisted/directed advertisements to the user

-> Can you please check my advertisements has whitelisted option properly in sniff log?
Galaxy, Windows PC also display advertisement whitelist enabled BLE.

Nordic_whitelist_filtered.pcapng

Here is no whitelist sample.
No difference, in my thought, was found advertisement packet between them.
Nordic_No_whitelist.pcapng

[Edvin]

Hello,

Sorry for the late reply. I had to do some research. Try removing the BT_LE_AD_GENERAL flag from your advertisement when you are using the whitelist. That should remove the LE General Discoverable. You must remove this flag only when you are advertising with a whitelist, and keep it when you advertise for accepting new connections.

Best regards,

Edvin

[Tim Hwang]

Thank you for updating.
Removing BT_LE_AD_GENERAL was not effective for me.
Without this flag, whitelist operation still works well. No bonding device can FIND BLE but cannot connect to it.
(As I told you, I'm not expecting no bonding device cannot find BLE)

static const struct bt_data adwlist[] = {
BT_DATA_BYTES(BT_DATA_FLAGS, (/*BT_LE_AD_GENERAL |*/ BT_LE_AD_NO_BREDR)),
BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_BUS_VAL),
};

#define BT_LE_ADV_WLIST_CONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE|BT_LE_ADV_OPT_FILTER_CONN, \
BT_GAP_ADV_FAST_INT_MIN_2, \
BT_GAP_ADV_FAST_INT_MAX_2, NULL)

err = bt_le_adv_start(BT_LE_ADV_WLIST_CONN, adwlist, ARRAY_SIZE(adwlist), sd, ARRAY_SIZE(sd));

[Edvin]

I think I was a bit confused about your sentence:

Tim Hwang said:

No bonding device can FIND BLE but cannot connect to it.
(As I told you, I'm not expecting no bonding device cannot find BLE)

I thought this meant that you had the expected behavior.

It is still possible to see advertisements even when you are using a whitelist. Advertisements are not encrypted or "invisible" for unbonded devices, as they use the same protocol and the same channels as the devices that are not bonded/using whitelist. The difference is that you will not be able to connect to a device that claims to be using whitelist if you are not on that whitelist. The whitelist itself is not broadcasted, so the bonded device will have to know whether or not it already knows the advertising device or not.

So the normal way to claim that you are using a whitelist is to disable the "General discoverable mode" flag, indicating that it is not a discoverable device. So if you don't know the device, you will not be able to connect to it. 

Yes, you can still see the device if you scan using nRF Connect for Android/iOS, but remember that this is a BLE developer tool, intended to display everything that it can find on the air. Typically in an custom application, you will filter out the devices with this flag set to false, if they are not bonded to that device. And typically, you would also filter on more things, such as an UUID or something. When you think of it, you will see a different selection of BLE devices if you are using a product's custom application than if you are using e.g. the phone's Settings -> Bluetooth tab.

So if your question is whether it is possible to be completely hidden for unknown devices, then the answer is no. Whatever you set in your advertisement is public information, and even if there was an option to hide everything, I could still sniff the data using a bluetooth sniffer. Try this by turning on a BLE keyboard or mouse without the computer that it is bonded with being turned on. You will see those advertisements on nRF Connect for Android/iOS/Desktop, or using a BLE sniffer.

But when you use a whitelist, I will not be able to connect to that device, unless I am already on the whitelist, because the peripheral in that case is able to refuse connection requests from unknown devices.

Best regards,

Edvin

[Tim Hwang]

BT_LE_AD_GENERAL was the key. Thanks.