PM_HANDLER_SEC_DELAY_MS

[Carlos]

Hello,

I would like to know what exactly is doing PM_HANDLER_SEC_DELAY_MS and  how can affect to the interoperability.

I saw in the bms example (sdk 15.2) it is set to 4000 and other examples it is set to 0.

Additionally, I would like to know which are the problems you have detected in order to create this define, in terms of which device (phone), which brands, versions, etc

And also what can be the deffect when the device is not operating due to this issue.

In my case, I use nRf52 peripheral that bonds with mobile phones, I am now experiencing several kind of issues of phone not able to connect the second time after bonding and other strange effects, I would like to know if this parameter can cause or be related to this behaviours (I used PM_HANDLER_SEC_DELAY_MS 4000 in my software because I merged the value from bms bond example).

Thank you!

[Kenneth]

Hi,

My recommendations is to use PM_HANDLER_SEC_DELAY_MS 4000. Because Apple Bluetooth guidelines says for instance:

https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

"23.10 Pairing The accessory should not request pairing until an ATT request is rejected using the Insufficient Authentication error code. See the Bluetooth 4.0 specification, Volume 3, Part F, Section 4 for details."

I would say it is good practice that the central initiate pairing/bonding, but it make sense that after a period of time that the peripheral can initiate security procedures if the central for unknown reason have failed to do so. So 4000 is a reasonable value.

You may check if you are somewhere calling pm_handler_secure_on_connection() and change that to pm_handler_secure_on_error() instead. 

Can you try to allow re-pairing by adding the following in pm_evt_handler() in main.c

case PM_EVT_CONN_SEC_CONFIG_REQ:
{
// Allow or 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;

Best regards,
Kenneth

[RTMerkel]

Howdy,

31.10 says "... should not" which the guild-lines states "2. Requirements... should not or not recommended means the full implications shall be understood before choosing this course."

Okay, a classic grey area. There is some internal debate between reading "should not" as "shall not" unless you have a really good reason to do so.

So my questions today are

1. Where does the 4000ms guidance come from? Conversations with Apple?
2. Does Nordic suggestavoiding pm_handler_secure_on_connection() due to Apples guidelines?

Thanks!