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've tested following cases when private scanning with BLE_GAP_SCAN_FP_ALL_NOT_RESOLVED_DIRECTED but no call sd_ble_gap_device_identities_set() anywhere:

1. 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 → SD asserts.
2. If advertising is ordinary then check for advertiser's name, if match then call sd_ble_gap_connect() with BLE_GAP_SCAN_FP_ACCEPT_ALL → SD connects.

Why?

[Einar Thorsrud]

Hi,

I am not sure why. I have to discuss it with the SoftDevice team and get back to you. But before that, I wonder what is the value of the program counter (PC) or the assert, which you get as a parameter to the error handler? Using that, I can see which assert was triggered.

[Basprog]

Dear Einar, I was a bit incorrect. Firstly SD stalls

0x00015C7C BF20      WFE
0x00015C7E BF40      SEV  <- here  
0x00015C80 BF20      WFE

R0 = 01000001, R1 = 40020518, R2 = 00000000, R3 = 00000001
R4 = 200000C0, R5 = 00000000, R6 = E000E000, R7 = 00000002
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000, R12= 00000000
R13= 20006D80, R14= 00015C7D, R15= 00015C7E, MSP= 20006D80, PSP= 00000000

If I do Stop then Run in Keil, SD asserts

0x0001475C D400      BMI   0x00014760
0x0001475E DFFF      SVC   0xFF          <- here
0x00014760 F8940022  LDRB  r0,[r4,#0x22]

[Einar Thorsrud]

Hi,

I see. This assert is expected, and not directly related to what we have discussed before. The assert is from the internal scheduler in the SoftDevice, which will assert if it has lost timing. It is expected that the SoftDevice asserts like this if you continue after a stop/breakpoint.