I am using SDK v15.3 and would like to modify the peripheral heart rate service example to require the Central to establish mode 1, level 3 security. I am undecided on whether it will be numeric comparison, passkey or OOB, but would like to evaluate each.
If there is another example I could reference to help with the changes to the heart rate service example, please advise.
Hi,
Sorry, forgot the context over the weekend. The default behavior of the nRF5 SDK as well is to reject re-pairing attempts for the reasons I explained in my previous points. You can allow re-pairing on that device too though, by doing as described in this post.
mlyonupdesigns said:What can I do from the central side if I have lost the bonding information but the peripheral has not? I'm just trying to understand what the spec says should occur in these instances.
The spec does not describe how this should be handled, it is up to the product designer. Generally, it is not a good idea to allow re-pairing. But for many small embedded devices it is needed. In the case you describe here, where the bonding information is lost on the central, the only way to recover is if the peripheral either has some mechanism to delete bonding data (for instance with a button press or similar), or if you allow re-pairing. It is commonly done, but as it is a potential security issue, it is prohibited by default in both the nRF5 SDK and nRF Connect SDK.
As described in the "post" you cite...will the LL_REJECT_IND sent by the peripheral trigger the PM_EVT_CONN_SEC_CONFIG_REQ, or more specifically, how is the central informed the the LL_REJECT_IND has been sent (this is received by the soft device, but I don't see how it bubbles up)?
No, it is not like that. If the central initiate pairing/bonding of the link, and the peripheral already have a bond with this central, you will get the PM_EVT_CONN_SEC_CONFIG_REQ event on the peripheral side. If you allow re-pairing by calling pm_conn_sec_config_reply() as shown in the mentioned post, a new pairing procedure will start. If not, the peripheral will send LL_REJECT_IND. If the device that initiated bonding (central in this case) is an nRF, you will get a PM_EVT_CONN_SEC_FAILED event at this point (when it has received the LL_REJECT_IND).
I have everything working now...thanks for the assistance.
I am running into an issue whenever an initial bonding operation occurs unrelated to the central connection with the heart rate service peripheral. My implementation also supports a single peripheral connection which is interacts with the central connection in the following way:
1. Peripheral advertising is enabled by default
a. Initiating advertising first sets the Tx power (sd_ble_gap_tx_power_set), updates the advertising message (sd_ble_gap_adv_set_configure) and finally starts the advertising (ble_advertising_start)
2. Upon starting to scan for heart rate service peripherals, the peripheral advertising is stopped (sd_ble_gap_adv_stop)
3. After connecting, bonding and enabling the heart rate service notification, the peripheral advertising is enabled again.
The above sequence worked perfectly prior to adding the bonding functionality. It works when connecting to an already bonded heart rate peripheral. However, it now fails reliably after step 3 above as follows:
...when calling sd_ble_gap_adv_set_configure() it returns NRF_ERROR_INVALID_STATE (see code snippet below). It doesn't matter whether the third parameter is NULL or not. I have confirmed that advertising is definitely being stopped and that I am calling the below function once prior to re-starting adverstising.
ble_gap_adv_data_t adv_data;
memcpy(&adv_data, p_profile->padvertising->p_adv_data, sizeof(ble_gap_adv_data_t));
if (p_profile->padvertising->adv_mode_current == BLE_ADV_MODE_IDLE)
{
result = sd_ble_gap_adv_set_configure(&p_profile->padvertising->adv_handle, &adv_data, &p_profile->padvertising->adv_params);
if (result != NRF_SUCCESS)
asm("nop");
}
else
{
result = sd_ble_gap_adv_set_configure(&p_profile->padvertising->adv_handle, &adv_data, NULL);
if (result != NRF_SUCCESS)
asm("nop");
}
I am willing to create a separate support question if that is desired.
You can disregard the last question...I have figured out the issue.
You can consider this question closed.
