• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 8 replies
  • Subscribers 64 subscribers
  • Views 44615 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 111938
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

connecting, bonding, pairing, and whitelists

GlennEngel

I'm a bit confused about nomenclature and am looking for guidance in how best to implement the needs of my ble app. From the S110 perspective, how are connecting, bonding, pairing, and whitelists related? What do these terms mean in relation to the device_manager?

For my application I can currently discover and connect from android and read and write characteristics. At this point I would like my ble device to only allow connections from the last successful connection until a reset procedure is initiated via a button press. I've read about irks and addresses and it really sounds like using a library is the way to go. I'm not concerned with security and passkeys for my application but wonder if I should be or if there is any downside. There is no visible ui on my ble device other than an led.

What is the most straight forward means of providing the connection storage, connection denial, and reset back to 'open'?

Parents
  • 0

    This is a short description of the terms, and how they are linked together:

    • Connection: A central (master) can connect to a peripheral (slave). While the connection is active the master and slave will communicate regularly at a determined interval. This connection interval can be between 7.5 ms and 4 s.

    • Pairing: Devices that are initially connected can exchange encryption keys and encrypt the link. When they have, the link is secure and they are paired.

    • Bonding: Paired devices can be bonded. This means that they store the keys that have already been exchanged when they paired and use those again the next time they connect.

    • Whitelisting: The whitelist is used to restrict connection or scanning from any other than predetermined (known) devices.

    The SDK provides libraries in order to assist in bonding and whitelisting: The older device manager and the new (currently experimental) peer manager. You can reset all the bonding information and disable the whitelist when desierd. E.g. with the peer manager you can delete all bonds with pm_peer_delete_all() and create a new empty whitelist (pm_wlist_create())and set it (pm_wlist_set()).

  • 0 in reply to Einar Thorsrud

    @awneil: Of course it should be 4 s. The "m" snuck in somehow, but I have updated the post now. Thanks for noticing!

    @GlennEngel: In principle you can use the whitelisting support in the SoftDevice without pairing or bonding. The whitelist is supplied to the SoftDevice in the call to sd_ble_gap_adv_start()`. However, that means that you need to use a non-standard way to retrieve the IRK from the peer initially, as it is used for whitelisting. In the unlikely case that your central does not use a private resolvable address (this rules out most phones etc.), you do not need the IRK, but can just use the static address instead.

Reply
  • 0 in reply to Einar Thorsrud

    @awneil: Of course it should be 4 s. The "m" snuck in somehow, but I have updated the post now. Thanks for noticing!

    @GlennEngel: In principle you can use the whitelisting support in the SoftDevice without pairing or bonding. The whitelist is supplied to the SoftDevice in the call to sd_ble_gap_adv_start()`. However, that means that you need to use a non-standard way to retrieve the IRK from the peer initially, as it is used for whitelisting. In the unlikely case that your central does not use a private resolvable address (this rules out most phones etc.), you do not need the IRK, but can just use the static address instead.

Children
No Data
Related

core_v2_widget.Hide()