This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Directed Advertising Peripheral

Hi

I have a Nordic nRF51 as a Peripheral. I have it open advertising until it connects for the first time to an Android handset.

When a connection is made it stays in directed mode advertising so that no other devices can connect in the future (for security purposes)

On a power cycle of the Android handset, it changes its address so I can never connect to the peripheral again, since its directing at the old handset address.

Any help would be much appreciated

Regards Luke

Parents
  • Hi Luke,

    You need to check what kind of address the Android phone has. If it's using random static address, I don't think there is anyway we can guess the new address to do correct directed advertising. If the phone has Resolvable Random Address, meaning there is a same IRK to generate the address. Then you need to exchange IRK and then do directed advertising with IRK. You can have a look at this example.

    Note that even you do directed advertising, other central device can still be able to connect to your device, there is nothing to stop them to do that. On the phone this function may be disable, but with a customized central or rooted phone, it should be possible.

    And easier way to reconnect a device previously bonded is to use whitelist, either on central or on peripheral.

    If you use whitelist on peripheral, you also need the IRK to detect the previously bonded phone.

Reply
  • Hi Luke,

    You need to check what kind of address the Android phone has. If it's using random static address, I don't think there is anyway we can guess the new address to do correct directed advertising. If the phone has Resolvable Random Address, meaning there is a same IRK to generate the address. Then you need to exchange IRK and then do directed advertising with IRK. You can have a look at this example.

    Note that even you do directed advertising, other central device can still be able to connect to your device, there is nothing to stop them to do that. On the phone this function may be disable, but with a customized central or rooted phone, it should be possible.

    And easier way to reconnect a device previously bonded is to use whitelist, either on central or on peripheral.

    If you use whitelist on peripheral, you also need the IRK to detect the previously bonded phone.

Children
  • Thanks for the response.

    On connecting event (BLE_GAP_EVT_CONNECTED), when I query: ble_evt->evt.gap_evt.params.connected.peer_addr

    The address type is BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE

    My question is, how will this direct advertising get to the handset since the Android handset is changing its address after a reboot.

    Luke

  • Yes, it's the resolvable address so it will change the address but usually will keep the IRK to generate the addresses. You need to follow what I described above. Do bonding and get the IRK from the keys exchange. Then follow the example that I quoted.

  • Are you referring to this code, as I cannot find a function in the nordic API for sd_ble_gap_device_identities_set()

    Also the irk in the example I assume needs to be a genuine irk not 0x00 to 0x0F. Where do I capture this irk?

    ret_code_t err_code;

    const ble_gap_id_key_t m_peer1 = { .id_info = { .irk = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}, } };

    const ble_gap_id_key_t * m_identities[] = {&m_peer1};

    err_code = sd_ble_gap_device_identities_set(m_identities, NULL, 1); APP_ERROR_CHECK(err_code);

    ble_gap_addr_t gap_addr = { .addr_id_peer = 0, };

    ble_gap_adv_params_t adv_params;

    memset(&adv_params, 0, sizeof(adv_params)); adv_params.type = BLE_GAP_ADV_TYPE_ADV_DIRECT_IND; adv_params.p_peer_addr = &gap_addr;

    err_code = sd_ble_gap_adv_start(&adv_params); APP_ERROR_CHECK(err_code);

  • Just looked and sd_ble_gap_device_identities_set() is only available in S132 which is for nRF52. I am using a nRF51, so this solution is not suitable. Please advise of other possibilities, as I am urgently trying to resolve this in my company Luke

  • Hi Luke,

    Sorry that I didn't check you are using S130. Advertising with privacy is not support on S130.

    In your case, I would suggest doing whitelisting. Whitelisting meaning you advertise in open, discoverable mode but only the central device that has been bonded with your can connect. The peripheral will discard the connect request from other central.

    Usually, what we do in our mouse and keyboard reference design is to advertise in directed advertising for a short period of time (few hundred milliseconds) before switching to normal advertising with whitelist. This is to take advantage of the high duty cycle adv interval directed advertising can have (3.5ms) to connect quickly. But this mode consume high power consumption so it should only be used short period of time.

    You can refer to our ble_app_mouse and keyboard example in the SDK to see how we do whitelisting.

Related