Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Pureer — Tue, 29 Jan 2019 14:33:54 GMT

Hi Einar,

I have successed after doing below action:

1.sd_ble_gap_device_identities_set , the addr type in the list MUST be public, static can't work.

2.sd_ble_gap_whitelist_set

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Einar Thorsrud — Tue, 29 Jan 2019 10:22:31 GMT

Hi,

The ble_advertising_whitelist_reply() only uses the count to know if IRK is used or not. It should have been set beforehand by a call to sd_ble_gap_whitelist_set().

You can see how this is handled in a normal case with bonding by seeing that the application cals pm_whitelist_set(), which in turn calls the internal peer manager function im_whitelist_set() which in the end calls sd_ble_gap_whitelist_set(). Then the whitelist can subsequently optionally be used when advertising or scanning.

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Pureer — Tue, 29 Jan 2019 06:09:39 GMT

You can have a look at ble_advertising_whitelist_reply,the function body is empty,IRK param is even not used,I don't think it will gonna work with this function.And I have tried several times , no success so far.

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

GK — Tue, 29 Jan 2019 05:20:16 GMT

I have tried once but was not successful..Need to do some more experiments on it....

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Pureer — Tue, 29 Jan 2019 03:43:14 GMT

Hi Einar ,

ble_advertising_whitelist_reply function is empty, the param is not used, IRK is not work if use this function.

uint32_t ble_advertising_whitelist_reply(ble_advertising_t * const p_advertising,
                                         ble_gap_addr_t    const * p_gap_addrs,
                                         uint32_t               addr_cnt,
                                         ble_gap_irk_t  const * p_gap_irks,
                                         uint32_t               irk_cnt)
{
    if (!p_advertising->whitelist_reply_expected)
    {
        return NRF_ERROR_INVALID_STATE;
    }

    p_advertising->whitelist_reply_expected = false;
    p_advertising->whitelist_in_use         = ((addr_cnt > 0) || (irk_cnt > 0));

    return NRF_SUCCESS;
}

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Pureer — Tue, 29 Jan 2019 03:40:43 GMT

Do you solve the problem? I have the one too!!! It suffers me.

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Einar Thorsrud — Tue, 08 Jan 2019 10:16:38 GMT

Hi Geetha,

Yes, that approach should work.

Einar

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

GK — Tue, 08 Jan 2019 10:10:14 GMT

Hi Einar Thorsrud,

Thank you for your reply.

I am planning to do the following.

I will use my Android phone with " HID Keyboard Application " and put some NRF_LOG_INFO() messages to print the IRK value ( received from phone). Then I will hard code those IRK value to use it with the whitelist before calling "ble_advertising_whitelist_reply()".

Is the above one a valid approach to use the IRK for whitelisting?

with regards,

Geetha

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Einar Thorsrud — Tue, 08 Jan 2019 09:44:31 GMT

Hi Geetha,

[quote user="GK"]If I consider an Android phone, will this IRK a unique value?[/quote]

Yes, the IRK is unique for each device.

[quote user="GK"]Is this value be a permanent one for a given Android phone?[/quote]

It should be permanent on Android phones (or any other device for that matter). If the IRK did change, then whitelisting (or any other operation where you want to resolve the identity of the android phone) would fail.

Br,

Einar

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

GK — Tue, 08 Jan 2019 09:09:27 GMT

HI Einar Thorsrud,

Thank you very much for your time and reply.

If I consider an Android phone, will this IRK a unique value?

Is this value be a permanent one for a given Android phone?

Please share your understanding.

Thanking you in advance.

with regards,

Geetha

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Einar Thorsrud — Tue, 08 Jan 2019 08:27:36 GMT

Hi Geetha,

There is strictly no need to be bonded in order to use whitelisting, but if the peer uses a resolvable address then you must have obtained the IRK in some way in order to do whitelisting. This is typically exchanged during the bonding procedure, so if not bonded you need another (custom) way of obtaining it.

If for instance the use case is that you want to whitelist a specific peer device during production, then you could program the IRK of the peer device to the nRF and use that for whitelisting. If it has to be done in the field, then you need some other way of providing the IRK to the nRF.

Br,

Einar

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

GK — Mon, 07 Jan 2019 10:13:20 GMT

Hi Einar Thosurd,

Thank you for your reply.

In the www.nordicsemi.com/.../ble_sdk_app_hids_keyboard

application it uses peer manager. When it comes to resolvable private address, we need to use IRK. Please correct me if I am wrong. And this IRK can be obtained after bonding happens. I think the bonding can be done only after establishing the connection. So the very first thing required is connection establishment , Am I correct?. But I need to use the whitelist before establishing the connection. Is there any way to do this?

Whrn the address is random static we can hard code the pre-known address and let the connnection happen only to that address... Is there a similar option with random resolvable address also?

Please share your thoughts on the same and Thanking you in advance.

with regards,

Geetha

RE: Using whitelist with 'BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE'

Einar Thorsrud — Wed, 02 Jan 2019 11:36:11 GMT

Hi,

You can refer to for instance refer to the HID Keyboard Application to see how whitelisting is implemented there. Essentially the Peer manager library which handles bonding also takes care of the IRK, so it is quite straightforward.