Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How could get the static address from a resolvable private address?

Let say a situation where I want to know if the just connected client is the same as the one that was last disconnected, but if the client uses RPA than have somehow to try with whatever is saved in the flash IRKs if it fits any of those in order to compare the static addresses ?

Thanks

Parents
  • Hi,

    I assume that since you mention IRK that the device have a bonded relationship with the peer device. In such case the IRK will be exchanged and stored to flash by the peer manager module in the nRF5 SDK, after bonding and disconnect, the device can then start advertising with whitelist and add the IRK's to the whitelist. The identity resolving is handled in BLE softdevice stack/hardware. You can for instance check out the HID BLE examples (mouse and keyboard) on how this can be done.

    Best regards,
    Kenneth

  • I'm looking in nRF SDK some alternative for what is available from other BLE SDKs - let say WICED:  wiced_bt_get_identity_address(RPA, identity_adress)  i.e. giving as input RPA, if the same peer device was already bonded, will  receive its static address in the  identity_adress parameter. 

    I can’t find anything like this neither in HID examples nor in SDK - the maximum I score to track - I could get a list of IRKs from a whitelist, then could iterate over and check each element of this list with pm_address_resolve () and could get ‘true’ if some of the tested IRK matches the RPA I’m interested in, but still will need somehow to get the static address from the IRK?

    Thanks

  • The private resolvable address will change over time (e.g. every 15minutes?), so not sure why you need it. But as an example I expect you can take a look at im_ble_evt_handler() on how to get the current peer address, where you can see that the BLE event do expose the address on the connected event (though likely on next connection event it will have changed if it is using private resolvable address):

    //On ble_evt->header.evt_id == BLE_GAP_EVT_CONNECTED event you can check:
    ble_evt->evt.gap_evt.params.connected.peer_addr;
    
    // Description of the peer_addr:
    /**@brief Bluetooth Low Energy address. */
    typedef struct
    {
      uint8_t addr_id_peer : 1;       /**< Only valid for peer addresses.
                                           This bit is set by the SoftDevice to indicate whether the address has been resolved from
                                           a Resolvable Private Address (when the peer is using privacy).
                                           If set to 1, @ref addr and @ref addr_type refer to the identity address of the resolved address.
    
                                           This bit is ignored when a variable of type @ref ble_gap_addr_t is used as input to API functions. */
      uint8_t addr_type    : 7;       /**< See @ref BLE_GAP_ADDR_TYPES. */
      uint8_t addr[BLE_GAP_ADDR_LEN]; /**< 48-bit address, LSB format. */
    } ble_gap_addr_t;

    Best regards,
    Kenneth

  • I never said I need the RPA - just the opposite - I need the static (or public) address (and will provide the RPA as input parameter)

    Thanks

Reply Children
Related