How to resolve Initiator's address when direct advertising?

[Basprog]

How to push Initiator to resolve its private address (seen at direct_addr of adv_report) when bonded private Advertiser does a direct advertising?

I need the only Initiator's own address to be resolved (based on device IRK) because I use software whitelisting for the reason of more than 8 peers so I don't call sd_ble_gap_whitelist_set() nether sd_ble_gap_device_identities_set(). As a consequence of no calls of these functions BLE_GAP_EVT_ADV_REPORT isn't fired when scan filter is BLE_GAP_SCAN_FP_ACCEPT_ALL. To receive adv reports filter should be changed to BLE_GAP_SCAN_FP_ALL_NOT_RESOLVED_DIRECTED but sd_ble_gap_connect() doesn't accept such setup.

I suppose the solution may be in pp_local_irks of sd_ble_gap_device_identities_set() but I can't get in mind how to use that based on description presented on Infocenter.

My case is most matched to variants #3 and #4 of Scan Private Devices MSC with the only difference: Advertiser's address shall remain unresolved because I'll resolve and whitelist it within BLE_GAP_EVT_ADV_REPORT handler by myself.

[Einar Thorsrud]

Hi,

I have discussed this more with the SoftDevice team, and the conclusion is that your approach is not possible. The reason is that the SoftDevice requires the IRK of the peer in order to resolve the destination address of the advertising packet. So after you have configured privacy using sd_ble_gap_privacy_set() you also need to call sd_ble_gap_device_identities_set() to set the peer and own identities. Then the observer will attempt to resolve the peer identity is resolved first before trying to resolve the own/destination identity. This requires bonding information (IRKs) in both devices, and you stuck with the limit of 8 devices. This is a limitation in the SoftDevice, but we believe it is in line with the Bluetooth specification as we have interpreted it.

The proposed solution is this (which may not be ideal, but we cannot think of any better in this case):

1. Set the list to the first 8 entries of the bigger list using sd_ble_gap_device_identities_set().
2. Start scanning using BLE_GAP_SCAN_FP_ALL_NOT_RESOLVED_DIRECTED.
3. On receiving of BLE_GAP_EVT_ADV_REPORT:
   1. If ble_gap_evt_adv_report_t::direct_addr.addr_id_peer is set than we found proper peer, so just call sd_ble_gap_connect() with BLE_GAP_SCAN_FP_ACCEPT_ALL.
   2. If that bit is not set then you need to try to resolve peer_addr and direct_addr using the rest of his bigger identity list in the app, starting from 9th entry. If the resolution is successful, set a new list that will contain found entry in the bigger table using sd_ble_gap_device_identities_set() and call sd_ble_gap_connect() with BLE_GAP_SCAN_FP_ACCEPT_ALL.

[Basprog]

Einar Thorsrud said:

the peer identity is resolved first before trying to resolve the own/destination identity

A bit strange solution up to me... This leads to skipping of an attempt to resolve own/destination address (while it may be present on identity list) and pushes to use the most unrestricted filter BLE_GAP_SCAN_FP_ALL_NOT_RESOLVED_DIRECTED which needs to be changed to BLE_GAP_SCAN_FP_ACCEPT_ALL when calling sd_ble_gap_connect().

[Basprog]

Dear Einar, I thought exactly the same about assert. So the rest question is why does SD infinitely wait for some event (stall) once got a request to connect to a directly advertising bonded private peer?

[Einar Thorsrud]

Hi,

It seems odd. This is the case: "If advertising is directed then check for target address, if successfully resolved then call sd_ble_gap_connect() with BLE_GAP_SCAN_FP_ACCEPT_ALL ", right? I assume the return value of sd_ble_gap_connect() is NRF_SUCCESS? Do you have a sniffer trace that shows the BLE traffic in this case? Does the nRF send the CONNECT_IND? If so, what happens in the air after that?

[Basprog]

Dear Einar, right this case. Return value is NRF_SUCCESS. For some reason my setup (nRF52-DK, nRF-Sniffer 2.0.0-beta-3, Wireshark 2.6.9) shows LE LL (advertising and scan) traffic only. But I clearly see that Peripheral continues to do a direct advertising after Central calls sd_ble_gap_connect() so I guess CONNECT_IND isn't happened in the air.

[Einar Thorsrud]

Hi,

I am not sure how much of the older discussion is still valid now. Is the peer device (peripheral) using privacy? If so, are you providing the peer identity address to the sd_ble_gap_connect() call? In any case, the CONNECT_IND will not be transmitted if the device is not found while scanning, which it will not be if it is using privacy and you have not set the identity list.

[Basprog]

Dear Einar, my question in other words is following: why does a connection to the directly advertising private peer require the identity list to be set while a connection to the ordinary advertising private peer not?

[Einar Thorsrud]

Hi,

I think that points back to the discussion in this thread a few weeks ago. You cannot resolve your own address without resolving the peer address. So you will not know that the peripheral is advertising to you.