Pairing specific pairs among many

RE: Pairing specific pairs among many

Einar Thorsrud — Fri, 18 Mar 2022 09:30:53 GMT

[quote user="June20"]Does pairing/bonding affect power consumption?[/quote]

The pairing procedure can consume a bit of power, especially if you use LESC. But this is a one time operation. Using encrypted packets on the link does not contribute significantly to power consumption.

[quote user="June20"]Can you please add rough code of central whitelisting just in case I decide to add IRK address please?[/quote]

If you want to use IRK (to use resolvable private address), then you need to bond. There are examples of bonding and whitelisting as central, for instance GATT Service Server Example Application. If you want to use resolvable address (in any role), you can refer to this post.

[quote user="June20"]I planning to change this thread into public since I didn't post my code, is it ok?[/quote]

Yes, that is more than OK. Public threads are preferable 🙂

RE: Pairing specific pairs among many

June20 — Fri, 18 Mar 2022 06:55:55 GMT

I guess I'll leave it on in case of no-address.

Does pairing/bonding affect power consumption?

Can you please add rough code of central whitelisting just in case I decide to add IRK address please?

I planning to change this thread into public since I didn't post my code, is it ok?

Seriously, those sample codes you added for peripheral was really helpful because sorting out APIs based on limited examples are VERY difficult, especially when functions' name are different based on SDK or version.

Always, thank you for answering.

RE: Pairing specific pairs among many

Einar Thorsrud — Thu, 17 Mar 2022 12:49:04 GMT

Hi,

[quote user="June20"]with whitelist and filter added, is bonding/pairing necessary? Can I get rid of both? I want to reduce connection time .[/quote]

That depends on your goal. With whitelisting, you ensure that only whitelisted peers can be connected. This is not related to pairing/bonding (other than in the cases where the devices use a resolvable address, the peer needs the IRK which it gets when bonding).

However, the primary point of pairing/bonding is to establish an encryption key that is used to encrypt the link. If you only whitelist, you will not have this, and anyone can listen in on the communication. Also, with bonding, some state information like the services etc. is stored between connections, and this is sometimes useful. If you only want to ensure that two specific devices can connect, and don't care about the other things (most notably encryption), then using only whitelisting is fine.

RE: Pairing specific pairs among many

June20 — Thu, 17 Mar 2022 01:19:45 GMT

[quote user="eith"] Remove the pm_* calls, and add code handling the whitelis manually, just like in the peripheral example I showed yesterday.[/quote]

I was asking for help on this part because central/scanner's API seems very different. Is sd_ble_gap_whitelist_set() enough for adding whitelist? A bit confusing because you added whitelist before advertising start and added again(?) during BLE_ADV_EVT_WHITELIST_REQUEST (which can be handled with ble_advertising_whitelist_reply)

Will adding whitelist with sd_ble_gap_whitelist_set() be enough before scanning? In whitelist_req and whitelist_load, there seems nothing but nrf_ble_scan_params_set() if I remove all pm_* and peer_*.

About the filter part, assuming peripheral is using whitelist with specific address (though BLE_GAP_ADDR_TYPE_RANDOM_STATIC), will there be any trouble connecting each other?

I know this one is bizarre, can gap address change or different when it is connected? I read ble address then added it UICR to connect it immediately but central's NRF_BLE_SCAN_EVT_CONNECTED is displaying totally different address when attempting to connect(then get disconnected).

EDIT: I did try filter on the central's side (disabled whitelist) while peripheral whitelist enabled. The problem still persisting is NRF_BLE_SCAN_EVT_CONNECTED - it is displaying different address then what I set on address filter. Funny thing is I'm getting NRF_BLE_SCAN_EVT_FILTER_MATCH.

I tried disabling whitelist on peripheral's side and it got connected this time. The problem is that the connected address is displaying totally different address ( I added nrf_log_info of p_ble_evt->evt.gap_evt.params.connected.peer_addr.addr on BLE_GAP_EVT_CONNECTED. Like central's case, it is displaying totally different address).

address difference eg:

Central's device address (NRF_FICR->DEVICEADDR[0,1]):

(hex) B331 9540 C817
(bin) 1011 0011 0011 0001 1001 0101 0100 0000 1100 1000 0001 0111

What peripheral is connected to (p_ble_evt->evt.gap_evt.params.connected.peer_addr.addr[0~5]):

(hex) 4095 31B3 17C8
(bin) 0100 0000 1001 0101 0011 0001 1011 0011 0001 0111 1100 1000

EDIT2: I found interesting pattern looking at both device: address array 123456 turns into 432165. Is it intended? does it affect filter and whitelist?

EDIT3: Holy Christ! I've been doing it wrong! after arranging peripheral's whitelist address in order/pattern I found, it worked! Scanner's filter address order is the same but peripheral's whitelist address has to be rearranged.

My Question changes: with whitelist and filter added, is bonding/pairing necessary? Can I get rid of both? I want to reduce connection time .

RE: Pairing specific pairs among many

Einar Thorsrud — Wed, 16 Mar 2022 09:42:48 GMT

Hi,

[quote user="June20"]

Edit: Central looks very tricky. hrs_c has whitelist-ing stuffs but it's related to peers

pm_peer_id_t says it is uint16_t, how does it carry whitelist data??

does central has something like ble_advertising_whitelist_reply()?

my central's NRF_BLE_SCAN_EVT_CONNECTED display totally different ble address compare to my peripheral's device address(NRF_FICR->DEVICEADDR[0,1]), is it possible?

[/quote]

Just as with peripherals, you don't need the peer manager to whitelist addresses. You can do it manually. But for a central this is related to scanning, and not advertising. Also as with the peripheral examples, you can see how it is done with the peer manager, but just replace the peer manager calls to get the whitelist from the peer manager with a whitelist you make yourself (which is just a list of addresses). I understand you already have referred to examples\ble_central\ble_app_hrs_c\main.c, and that is a good reference. Here you have the whitelist being handled mostly in the whitelist_load() and on_whitelist_req() functions. Remove the pm_* calls, and add code handling the whitelis manually, just like in the peripheral example I showed yesterday.

Another point though is that whitelisting might not be relevant on the central. It is mostly useful when using IRKs as then the stack will handle address resolution etc. for you. If you just have a specific static address you want to connect to, then you can simply select to connect to that address. If you look at the scan_init() implementation in the same example you can see it filters on different things. You can simply filter on the address, and that is that.

[quote user="June20"]

Peripheral's side doesn't respond much but central's side constantly find connection and get disconnected for reason 2 and 3e

what does it mean unknown connection identifier?

I believe BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHEDd is due to constantly trying to connect?

[/quote]

I guess this is with the whitelisting code? That has whitelisted a device I used to test, so you need to change the hard coded address to use another device. BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED (0x3e) is the expected disconnect reason when trying to connect with a device that use whitelist and you are not in it. That is because the peripheral will simply ignore connections from a central that is not in the whitelist. I am not sure why/where you would see BLE_HCI_STATUS_CODE_UNKNOWN_CONNECTION_IDENTIFIER (2), though..

RE: Pairing specific pairs among many

June20 — Wed, 16 Mar 2022 02:12:04 GMT

Perfect!

Could you be so kind to do another one for central/scanner please?

Edit: Central looks very tricky. hrs_c has whitelist-ing stuffs but it's related to peers

pm_peer_id_t says it is uint16_t, how does it carry whitelist data??

does central has something like ble_advertising_whitelist_reply()?

my central's NRF_BLE_SCAN_EVT_CONNECTED display totally different ble address compare to my peripheral's device address(NRF_FICR->DEVICEADDR[0,1]), is it possible?

Also,

Peripheral's side doesn't respond much but central's side constantly find connection and get disconnected for reason 2 and 3e

what does it mean unknown connection identifier?

I believe BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHEDd is due to constantly trying to connect?

RE: Pairing specific pairs among many

Einar Thorsrud — Tue, 15 Mar 2022 13:03:56 GMT

Hi Joon,

None of the pm_* APIs are relevant if you don't use bonding. I referred to pm_whitelist_get() just to see where it gets the whitelist (which is simply a list of addresses) from the peer manager and how to use it.

You can see a very simple way to do whitelisting manually here:

devzone.nordicsemi.com/.../1682.main.c.diff

(this is not very elegant as I just did minimal changes needed for the HRS example without caring about code duplication. As you can see if you compare with the HID mouse example it is basically the same thing, just that you provide the list of addresses (or just one address in this case) yourself instead of getting it from the peer manager.

RE: Pairing specific pairs among many

June20 — Mon, 14 Mar 2022 08:43:35 GMT

Thanks for the reply

I will be using nRF52840 and nRF52833 so I don't think I will use IRK.

peripheral/ble_app_hids_keyboard has case BLE_ADV_EVT_WHITELIST_REQUEST: and pm_whitelist_get, but not pm_whitelist_set. pm_whitelist_set has weird parameter which is pm_peer_id_t also uint16_t. I don't think the parameter has to do with ble address (48bit or 6byte + BLE_GAP_ADDR_TYPE_RANDOM_STATIC).

I did stumble upon sd_ble_gap_whitelist_set() but it did not affect pm_whitelist_get().

Can you tell me how to add whitelist manually using address?

EDITS:

sample of code will be very nice, I can't really pull much from s140 hids keyboard BLE_ADV_EVT_WHITELIST_REQUEST.

RE: Pairing specific pairs among many

Einar Thorsrud — Fri, 11 Mar 2022 09:22:50 GMT

Hi,

[quote user="June20"]I guess if I increase whitelist, the FDS part will increase too.[/quote]

The whitelist itself does not rely on FDS. But you need to store the information somewhere, and the most typical use case is to whitelist bonded peers. Those are stored in FDS (by the peer manager). The FDS pages are determined by sdk_config.h though, so this is static. It is just that the more data you have, the more of the allocated space you use. You can read more about FDS here if that is relevant.

[quote user="June20"]About whitelist, I can't find much about whitelist create in SDK 17.1.0 version. Is there a way to create a whitelist without connection/pairing/bonding? (I have other address for connection)[/quote]

Yes, even though the SDK examples use bonding, you can do it with a raw address as well. Note one important point, though. Phones typically use resolvable addresses, and you only get the identity resolution key (IRK) via bonding. So whitelisting will not work properly with phones unless you bond with them. That said, to use whitelisting with specific addresses you build the whitelist yourself instead of using the peer manager (pm_whitelist_get()). So if you search for BLE_ADV_EVT_WHITELIST_REQUEST you can see where the whitelist is provided to the BLE stack, and this is where you need to insert your "manually" built whitelist instead.

RE: Pairing specific pairs among many

June20 — Fri, 11 Mar 2022 03:01:40 GMT

Thanks for the answer.

I guess if I increase whitelist, the FDS part will increase too.

About whitelist, I can't find much about whitelist create in SDK 17.1.0 version. Is there a way to create a whitelist without connection/pairing/bonding? (I have other address for connection)

Old version SDK has pm_whitelist_create but newer version does not.

RE: Pairing specific pairs among many

Einar Thorsrud — Thu, 10 Mar 2022 07:46:33 GMT

[quote user="June20"]I didn't really used any FDS, is it from SoftDevice?[/quote]

No, the SoftDevice does not use FDS (or persistent flash storage of any kind). However, the peer manager, which is responsible for pairing and bonding use FDS to store bonds. So if you are using the peer manager, you are using FDS. The number of FDS pages are configured in sdk_config.h (default in moste examples are 3, and absolute minimum is 2).

[quote user="June20"] Since BLE central can use filter, is there a way for peripheral to filter scanners (by ble address/name/etc.)?[/quote]

For peripherals it is a bit different, as it is the central that connects. However, whitelisting is also a concept on the peripheral side. If you advertise with whitelist, only peers that are in the whitelist are allowed to connect. Connections from other centrals are automatically dropped by the stack. This only allows you to filter on address, though. If you need to filter on something else (like name), then you must allow it to connect, read whatever information you want to check, and disconnect if that does not match your criteria.

RE: Pairing specific pairs among many

June20 — Thu, 10 Mar 2022 05:11:38 GMT

The third area at top I was talking about was 0xFD000 ~ 0xFD007 (8byte). I think you're right, Flash Storage - NRF_FSTORAGE_ DEF from info center mentions 0xFD000 address (though mine from fds.c doesn't mention any address). I didn't really used any FDS, is it from SoftDevice?

UICR was very useful, I was able to narrow down to the specific peripheral from BLE central. Since BLE central can use filter, is there a way for peripheral to filter scanners (by ble address/name/etc.)?

RE: Pairing specific pairs among many

Einar Thorsrud — Tue, 08 Mar 2022 13:14:47 GMT

I assume that the extra block you see close to the top are FSD pages. FDS is (among other things) used for persistent storage by the peer manager module, and these flash pages are initialized the first time after reset. You can hover over it to see the address range to compare with your memory layout to be 100% sure (refer to memory layout figure in the bootloader documentation to get an overview of what you are looking at).

RE: Pairing specific pairs among many

June20 — Tue, 08 Mar 2022 03:02:33 GMT

Thanks, what I was looking for was UICR, and it checked out when I used "nrfjprog --memwr 0x10001080 --val 0xcc"

I am now stuck with binary(or hex) files.

nRF Programmer is showing different memory layout when comparing what I debug via Segger studio versus output/my_app.hex + softdevice_s140.hex.

Are there other hex file I should consider? (I also added bootloader_setting.hex I generated but they don't seem to be identical.)

Top two lines on the right side is bootloader_setting.hex, and the rest are my_app.hex + softdevice_s140.hex

bootloader_setting.hex (nrfutil settings generate --family NRF52840 --application "my_app.hex" --application-version 0 --bootloader-version 0 --bl-settings-version 2 bootloader_setting_uicr.hex)

Also, are there any easy-to-follow nrfjprog tutorial?

Thanks

RE: Pairing specific pairs among many

Einar Thorsrud — Wed, 02 Mar 2022 13:24:31 GMT

Hi,

[quote user=""]

We did make custom boards and also made a program that once paired(bonded), it won't connect with others.

(eg, once nRF52840 and nRF52833 is paired, it will not connect with others)

[/quote]

This sounds like what you normally achieves with whitelisting. I assume that is what you are using?

[quote user=""]We were wondering is there a way to make specific central connect with specific peripheral?[/quote]

If they are already bonded/paired, whitelisting is what you typically use here. That can be used on both the peripheral side and central side. With that, the device will only connect with a peer that has a specific BLE address (either static or derived from a IRK).

[quote user=""]Is there a way to make each central/peripheral unique so that pairing process can be done without interference?[/quote]

If you want to do this without any user interaction and want it to be secure, then it is difficult. But if it is just for convenience, then you could base this on BLE address. Or you could for instance use a unique number in for instance the name of the device and include that in the advertising packets, and have the central search only for a device with a specific name including a unique number.

[quote user=""]extra question: is there a way to write certain unique number/MAC address on flash during flash write and then read it during application?[/quote]

Yes.

[quote user=""]How do I know which address of flash is used or not?(want to avoid collision with bonded info)[/quote]

If it is just a serial number of address or similar, then the most natural is to put this in UICR. Then it does not conflict with anything else as long as you stay away from the reserved parts. See UICR chapter in PS for details. Then you can read this like any other part of the flash/memory. If you need to store a lot of data or need to be able to update the data, you need to do this differently. That does not seem to be the case here, though(?).