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)
