How to resolve random ble address

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi All,

I am using Wiced_SDK_3.5.2.

I am trying to remember the link keys of bonded device for BLE. I have observed that the static address is same is BT address of android phones. Next time whenever the same device requests for link key, I see that the BLE address is random.

I wanted to know how to resolve the Random address to a physical address?

Quick response is highly appriciated.

Thanks in Advance.

0 Likes
5 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

To my knowledge, the only way to resolve a changing address within a single power cycle is for it to abide by the spec definition of Random Private Resolvable (Vol3 Part C 10.8.2.2). These addresses require an Identity Resolving key (IRK) to resolve the address using a hash algorithm. When using the API to add a device and its key to the address resolution (wiced_bt_dev_add_device_to_address_resolution_db), you must specify the IRK of the device so that the lower layers can match the changing address with the proper keys. The IRK should be transferred during the pairing procedure.

Specify the IRK:

          wiced_bt_device_link_keys_t      keys;

          uint8_t my_irk[16] = {.....};         

          memset(keys.key_data.le_keys.irk, my_irk, 16);

          wiced_bt_dev_add_device_to_address_resolution_db(&keys, BD_ADDR_RANDOM);

Jacob

Anonymous
Not applicable

Hi Jacob,

Thanks for the response.

I wanted to remember the link keys over power cycle. In this case how do we have to manage.

Can you please share the which API needs to be used when we receive each BT stack callback event.

However I wanted to know if I have static address, can I still add to address resolution DB with parameter ADDRESS_PUBLIC.

Thanks in advance.

0 Likes

In order to store link keys through power cycles, you'll need to implement an app DCT which essentially stores the entire wiced_bt_device_link_keys_t struct for as many keys as you plan to store.

A) Every time you receive a BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT event in  your management callback, store the key and bd_addr into device resolution using the API:

     wiced_bt_dev_add_device_to_address_resolution_db

Then store it into the DCT.

B) On every boot, go through each DCT entry, and for every valid entry, load them one-by-one into the device resolution using the same API as above.

C) Also respond BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT events with true or false depending on whether your DCT contains the proper keys.

wiced_result_t ble_central_management_cback( wiced_bt_management_evt_t event,  wiced_bt_management_evt_data_t *p_event_data)

{

    switch( event )

    {

        case BTM_ENABLED_EVT:

            //load keys stored in NVRAM into device resolution one by one

            break;

        case BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT:

            //store the device into NVRAM and load it into resolution

            break;

        case  BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT:

            //based on the bd_addr go through and check if the key for the address exsts

            //if they exist in NVRAM, return true, else false

            break;

        default:

            return result;

            break;

    return result;

}

Side note:

The BT stack actually provides a way to register for interrupts for nvram storage functions outside of the management callback, which override the normal callbacks.

You will still need to implement the DCT storage yourself, but the event can be handled outside of the management callback. This will be more work because of the number of functions you must define and register callbacks for.

See wiced_bt_nvram_access.h for details.

In my opinion, you're better off leaving this alone and just interacting with the DCT through the management callback.

Jacob

Anonymous
Not applicable

Hi Jacob,

Thanks for the detailed explanation.

But I we are seeing that the LinkKey Update event comes 4 times once pairing is successful. Out these 4 times, first 3 times we get random address, but for 4th time it is always the static address(BT mac address of Remote device). Hence I will endup storing static address against the IRK keys of the peer device. In this case how do we match the BLE address.

So I wanted to know if this behavior is expected?

Once the keys are stored which is the to get Link keys. Is this the API?

wiced_result_t wiced_bt_dev_get_ble_keys(wiced_bt_device_address_t bd_addr, wiced_bt_dev_le_key_type_t *p_key_mask);

PFA pairing complete event info.

image (1).png

Thanks in advance

0 Likes

hi nishal - were you able to come to conclusion on this?

I am seeing the same behavior you describe - the update event is provided 4 times, the last containing the static address.  At next boot, the bonded device doesn't provide the same address.

0 Likes