Hi Chris,
Currently I have been able to develop an app which is able to store bond
information in NVS flash. If my device (ESP32) based on NIMBLE stack is
rebooted, the bond remains intact. But if the other device is rebooted
the ` key_sec->peer_addr.val` gets changed based on
`key_sec->peer_addr.type = 1` (static address, random device address).
As I understand, it is expected of static address type to change to new
value, generated after each power cycle.
So in this case how to keep bond between devices intact ?
If in case static address type is not to be used for bonded devices then
why our NIMBLE stack uses static type of address even after setting
`bonding` flag to 1 ?
Could you help me resolve this issue? Or I am missing on something obvious?
Below is the snippet of code which tries to retrieve index from database
but fails to do so since the `peer_addr.val` field has been changed.
`
if (ble_addr_cmp(&key_sec->peer_addr, BLE_ADDR_ANY)) {
if (*ble_addr_cmp(&cur->peer_addr, &key_sec->peer_addr*)) {
continue;
`
Regards
Prasad
On 14/02/19 11:53 AM, prasad wrote:
Hi Chris,
Thank you for your response. As I build my understanding from your
response,
The `idx` field most probably is useful in searching the case where
`key.sec.peer_addr = *BLE_ADDR_ANY`, which most probably is useful to
search our security keys. Correct me if I am wrong.
The reason behind asking use-case of `idx` was, when we are to write
security keys to database, we call `ble_store_key_from_value_sec`
which does the following:
{
out_key->peer_addr = value->peer_addr;
out_key->ediv = value->ediv;
out_key->rand_num = value->rand_num;
out_key->ediv_rand_present = 1;
*o**ut_key->idx = 0;* // /This made me wonder why we need to search
based on this criteria./
}
Thank you for response anyways. Really helpful.
Regards
Prasad
On 13/02/19 9:44 PM, Christopher Collins wrote:
Hi Prasad,
On Wed, Feb 13, 2019 at 03:13:26PM +0530, prasad wrote:
Hi all,
As it happens, I fixed the bug in my code. It now correctly retrieves
LTKs and bond is maintained even after reboot.
Apart from this I just wanted to understand reason behind including
'idx' in structure 'ble_store_key_sec'. Could you please help me
understand use-case behind including 'idx'?
/** Number of results to skip; 0 means retrieve the first match. */
uint8_t idx;
The `idx` field is useful when your search criteria matches several
entries and you want to process them one by one. For example, the
`ble_store_iterate()` function constructs a `ble_store_key_sec` object
with the following values:
{
/**
* Key by peer identity address;
* peer_addr=BLE_ADDR_NONE means don't key off peer.
*/
peer_addr = *BLE_ADDR_ANY,
/** Key by ediv; ediv_rand_present=0 means don't key off ediv. */
ediv = 0,
/** Key by rand_num; ediv_rand_present=0 means don't key off rand_num.
*/
rand_num = 0
ediv_rand_present = 0,
/** Number of results to skip; 0 means retrieve the first match. */
idx = 0,
}
Then it repeatedly calls `ble_store_read()`, incrementing the `idx`
member each time. This allows all stored bonds to be processed.
Chris)
