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 am having some problems getting a clear picture of what you want to do. Can you explain in a bit more detail?

Based on the topic, it seems to me that the nRF is a peripheral, and you ask how it can do central address resolution?

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

Here it seems like you are working on the central, and want to check if an advertisement packet is for you, but I am not sure.

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.

My understating here is this:

• An nRF is a central/initiator that use privacy (changes address regularly based on IRK)
• The peripherals will do directed advertising towards the nRF (using address obtained by central address resolution?)
• The nRF will accept all directed advertisement packets - no whitelisting is used at the SoftDevice level.

Is it correct? So the nRF should just check if the advertisement packet was for itself? If so, that should be handled by the SoftDevice provided you set the IRK using sd_ble_gap_privacy_set().

[Basprog]

Einar Thorsrud said:

nRF should just check if the advertisement packet was for itself?

Dear Einar, yes, I need exactly that from S132.

Einar Thorsrud said:

that should be handled by the SoftDevice provided you set the IRK using sd_ble_gap_privacy_set()

I also expected the same but it's not.

Steps to reproduce the issue: bond private S112 with private S132, both use sd_ble_gap_privacy_set() for sure, let S112 to advertise directly towards S132, don't use sd_ble_gap_whitelist_set() nether sd_ble_gap_device_identities_set() on S132, observe no adv reports when scan filter is SCAN_FP_ACCEPT_ALL, observe adv reports with unresolved direct_addr when scan filter is SCAN_FP_ALL_NOT_RESOLVED_DIRECTED.

[Einar Thorsrud]

Hi,

I did not get the chance to test this today, but it is a bit surprising. I would have expected the central to resolve the address of the directed advertisement packets automatically (central address resolution), provided you configure privacy using pm_privacy_set() (or sd_ble_gap_privacy_set() directly). As you write, sd_ble_gap_device_identities_set() should not be needed as you don't use whitelisting.

Do you have the code you used to test this in a state where it can be shared and run on a pair of  DKs? Also, do you have a sniffer trace that shows the initial connection, and then subsequently directed advertisements?

[Basprog]

Dear Einar, I can't post my code here due to confidentiality. But you may take any pair of central and peripheral examples in SDK then just add few lines to enable the privacy and more detailed log of adv_report. I've not captured any sniffer trace.

I do also observe one more strange thing related to direct advertising: if identity and white lists are in use, direct_addr in adv_report holds resolvable address and its addr_type is RANDOM_PRIVATE_RESOLVABLE while addr_id_peer is 1, however peer_addr holds identity address, its addr_type is RANDOM_STATIC and addr_id_peer is 1.

[Basprog]

Dear Einar, enough time have passed. Do you have any progress here?

Please let me know if there's a dedicated bug report thread, I'll post my observations there.

[Einar Thorsrud]

Hi,

I am sorry for the late reply. I have been testing a bit and discussing with a SoftDevice developer, but we are not sure what is happening.

A common problem when you want to advertise to the initiator's resolvable address is that you must make sure that your own address is also resolvable. This does not seem to be the problem in this case since you wrote "both use sd_ble_gap_privacy_set()", though.

Would it be possible for you to make the small modifications to the example that you described so that we know that we are looking at the same code as you are?

Edit: Can you verify that the address type in the call to sd_ble_gap_privacy_set() is BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE in both ends?

[Basprog]

Dear Einar, may I know what you've tested exactly? Have you got a setup/code which meets your expectation or BLE specification? I do still prefer you to take a pair of examples from SDK, enable the privacy on both ends then check how the direct advertising works - this will be a really clear test.

My central and peripherals use the same code to enable the privacy:

ble_gap_privacy_params_t privacy_params = {0};

privacy_params.privacy_mode      = BLE_GAP_PRIVACY_MODE_DEVICE_PRIVACY;
privacy_params.private_addr_type = BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE;
APP_ERROR_CHECK(sd_ble_gap_privacy_set(&privacy_params));