SDK15 paring problem

[Bing]

Hi nordic,

I am using SDK15.0 (NRF52840) to design a watch producation which needs pairing. I have a problem that if NRF52840 (peripheral ) has been paired with a smartphone (central), and then I remove the bonded deivce on smartphone side and try to connect the NRF52840 device which bond is removed, the smartphone will be rejected to pair (both android and iphone). As I know, the SDK11.0 has no same problem. If we do the samething between NRF52832 (SDK11.0) and smartphone, when reconnect, the users just need to repair them with no problem.

And If I remove the bonds on NRF52840 side (use function delete_bonds()), then the smartphone will successfully repair the NRF52840.

So I have the following questions:

1 Whether can I implement the same experience as SDK11.0 about the above problem?

2 What is the main difference of bond manager between SDK11.0 and SDK15.0 function?

3 I can define the maximum bonds can be stored in SDK11.0, but SDK15.0 seems to have no same feature. Then what is the purpose of the new (SDK15) design?

If any wrong understanding, please kindly  correct me.

Thanks.

[Einar Thorsrud]

Hi Wang,

The Peer manager in SDK 15 does not allow re-pairing by default. This means that it will reject a pairing request from an already bonded peer, which is what you are seeing.

1. You can allow repairing by setting allow_repairing to true in the pm_conn_sec_config_t that you pass to pm_conn_sec_config_reply in the handling of the PM_EVT_CONN_SEC_CONFIG_REQ event. For instance like this (Modified from rom the ble_app_hrs example in SDK 15.0):

 

        case PM_EVT_CONN_SEC_CONFIG_REQ:
        {
            // Reject pairing request from an already bonded peer.
            pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
            pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
        } break;

2. The bond manager and peer manager are different in many ways (totally different libraries, though both handle paring and bonding). The relevant difference in this case is that the examples in SDK 15 don't allow re-pairing by default in order to be more secure, but this can be changed by the application developer if needed (as above) if user friendliness is more important than security (which it often is in practice).

3. The Peer manager does not have a fixed maximum number of bonds. However, it will be limited by the available space in FDS (flash), which you can configure by setting FDS_VIRTUAL_PAGES in sdk_config.h. You can achieve a fixed number if you like by checking the number of peer using pm_peer_count() every time a new bond is made, and delete the oldest pair if the number is higher than the limit you would like.

Best regards,

Einar

[Bing]

Thanks for your reply. The anwsers are very helpful for me.  I checked the default configuration for FDS_VIRTUAL_PAGES is 3. And one of the virtual page is used for garbage collection by system. So there is just 2 virtual pages can store bonding information.

I want to know more:

1 How many bytes a bond is? If FDS is just used to store bonding information? How many bonds can be stored?

2 If I set the pm_conn_sec_config_t::allow_repairing to true, when repairing, will the peer manager allocate a new postion or search the original postion for this bond?

3 If stored bonds arrive the maximum number, when the next peer device pairs with this deivce, what will happen?

4 Whether I can delete a specified bond by call pm_peer_delete(pm_peer_id_t peer_id)? And I want to know how to obtain the peer_id for all of the bonds stored or a specified bonds identified by something (for example, bt address)?

[Einar Thorsrud]

Hi,

1. A bond is typically about 38 words (152 bytes), but it can be a bit higher with multiple CCCDs.

2. The Peer manager will replace the existing bond in this case.

3. The application will get a PM_EVT_STORAGE_FULL event from the peer manager if it is unable to store a bond due to full FDS. The examples will do a FDS garbage collection at that point, but it will only free space if some data has already been marked as deleted. You can free more space by deleting the oldest peer first. (Generally managing bonds is up to the application, but the peer manager provides the necessary tools with API functions like pm_peer_count(), pm_peer_ranks_get(), pm_peer_delete() etc.)

4. Yes, you can delete a specific bond as you suggest. However, there are no API for searching for peers with a specific BT address or similar. You could implement that yourself though (but I fail to see the typical use case for such a feature). Typically you would want to delete the oldest peer (longest time since it was connected) if you run out of storage for bonding information. This is handled by ranking peers by when they were last seen, as is done in the SDK examples.

[RTMerkel]

Einar,

How would this (not allowing re-pairing) work in the field? For example 

1. Customer has paired and bounded their phone to with a device… all is right with the world.
2. Customer accidently tells their phone to “forget” the device, now the mobile application can no longer talk to the handle. Customer is not amused.
3. I suppose that the App might be able to detect a connection error and tell the user to do something that would clear all the bounding data on the handle, like putting the handle on a charger, and pressing a button 10 times... but yuck.

Suggestions?