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

[Carlos]

Thank you for your reply.

For PM_HANDLER_SEC_DELAY_MS  I think it is clear. Thanks, I will keep it to 4000.

>>You may check if you are somewhere calling pm_handler_secure_on_connection()

>>and change that to pm_handler_secure_on_error() instead. 

What is the purpose of this change? 

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

What this will exactly do? If we have a bond to the peer remove bond and try to bond again?

What are problem or benefits on doing this? I think there may be a security problem if we allow this.

Is there any other trick or advice to consider, based on your experience, to increase the compatiblity of nRf with different phones (manufacturers, os versions, etc)?

Thanks,

[Kenneth]

Carlos said:

>>You may check if you are somewhere calling pm_handler_secure_on_connection()

>>and change that to pm_handler_secure_on_error() instead. 

What is the purpose of this change? 

Don't trigger security procedure upon connection, instead only if it fails. 

Carlos said:

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

What this will exactly do? If we have a bond to the peer remove bond and try to bond again?

What are problem or benefits on doing this? I think there may be a security problem if we allow this.

It will allow bonding from a phone that may have erased it's own bond. I agree it may be a security risk to do so, but for testing to see if it affect the issue you are experiencing it may be worth a test. 

I am now experiencing several kind of issues of phone not able to connect the second time after bonding and other strange effects

I think an on-air sniffer trace when it fails will show the actual reason. I am not aware of any specific issues.