HCI_LE_Read_Local_Resolvable_Address not implemented in Softdevice Controller

[Cyril Praz]

Hello,

As the  LE Audio controller for nRF5340 library is deprecated in favor of the Nordic Semiconductor’s standard Softdevice Controller. We have started to use the Softdevice Controller.

Unfortunately it appears that this controller stack doesn't implement the HCI command HCI_LE_Read_Local_Resolvable_Address (0x202C) which we are using for a testing purpose.

This HCI command is optional but was implemented in the LE Audio controller stack.

Do you know if it will be implemented in a near future? If not, is it possible to get this information by another mean with an sdc_xxxx function ?

Our actual version of the SDK is as follow:

sdk-nrf version: v2.6.1

zephyr version: v3.5.99-ncs1-1

Best regards,

Cyril

[AHaug]

Hi,

In NCS you can use bt_id_get() as illustrated in the Beacon Sample to get public addresess, i.e as

	/* For connectable advertising you would use
	 * bt_le_oob_get_local().  For non-connectable non-identity
	 * advertising an non-resolvable private address is used;
	 * there is no API to retrieve that.
	 */
 
	bt_id_get(&addr, &count);
	bt_addr_le_to_str(&addr, addr_s, sizeof(addr_s));
 
	printk("Beacon started, advertising as %s\n", addr_s);

Alternatively I found this suggestion to read local resolvable private addresses (needs to be verified that it works as expected) using the function `BT_HCI_OP_LE_READ_LOCAL_RPA`.

 Here is the definition from the [Zephyr's HCI types documentation](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/doxygen/html/hci__types_8h.html#bthcioplereadlocalrpa):

#define BT_HCI_OP_LE_READ_LOCAL_RPA BT_OP(BT_OGF_LE, 0x002c) /* 0x202c */

The structure `bt_hci_rp_le_read_local_rpa` is used to read the status and local resolvable private address (local_rpa). Here is the structure from the [Zephyr's HCI types documentation](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/doxygen/html/hci__types_8h_source.html):

 

struct bt_hci_rp_le_read_local_rpa {
    uint8_t status;
    bt_addr_t local_rpa;
} __packed;

I would suggest that you investigate the first alternative first, but if this is not up to par with your requirements, then the second alternative might be what you need.

Kind regards,
Andreas

[Cyril Praz]

Hello,

thanks for the quick reply!

bt_id_get is not a solution for me. This function is returning an identity address which can be either a public address or a random static address.

Moreover bt_id_get  is implemented into the host stack and when you are using the resolving list the resolvable private address is generated into the controller stack.

The second solution is what I tried and I have the HCI error UNKNOWN_HCI_COMMAND (0x01)

We can see here that the opcode is not present: https://github.com/nrfconnect/sdk-nrfxlib/blob/v2.6.1/softdevice_controller/include/sdc_hci_cmd_le.h#L108

The feature "hci_le_read_local_resolvable_address" declared here: https://github.com/nrfconnect/sdk-nrfxlib/blob/v2.6.1/softdevice_controller/include/sdc_hci_cmd_info_params.h#L404

is not defined here: https://github.com/nrfconnect/sdk-nrf/blob/v2.6.1/subsys/bluetooth/controller/hci_internal.c#L431

finally here we can see that the HCI opcode 0x202C is not handled: sdk-nrf/subsys/bluetooth/controller/hci_internal.c at v2.6.1 · nrfconnect/sdk-nrf · GitHub

I try to find here: github.com/.../include if there is another non HCI function linked to the library to get this information but I didnt found it.

[AHaug]

Hi,

Cyril Praz said:

bt_id_get is not a solution for me. This function is returning an identity address which can be either a public address or a random static address.

Noted

Cyril Praz said:

The second solution is what I tried

Ah, you're right. I see that now when I reread your query. Thank you for elaborating around that. I will ask the SoftDevice Controller team directly for some input regarding the HCI_LE_Read_Local_Resolvable_Address command support.

I'll get back to you when I hear back from them

Kind regards,
Andreas

[AHaug]

Hi again,

Here's some info from the developers and some follow up questions:

The HCI_LE_Read_Local_Resolvable_Address is optional to implement and we have decided to not implement it because using the command in itself results in a race condition -> The returned address may already be outdated when read by the application.

Could you expand upon how your application intends to use this command? The NCS Bluetooth stack generates all resolvable addresses in the Bluetooth host (not the controller). Therefore, this command doesn't return a resolvable address. 

The developers also asks if maybe what you want to know is what advertising address is being used? The audio application does that here: https://github.com/nrfconnect/sdk-nrf/blob/main/applications/nrf5340_audio/src/bluetooth/bt_management/advertising/bt_mgmt_adv.c#L133

Kind regards,
Andreas

[Cyril Praz]

Hello,

The HCI_LE_Read_Local_Resolvable_Address is optional to implement and we have decided to not implement it

You have right and that's the answer I was afraid to get ^^

We have an application with another host stack and another controller stack.

To simulate a phone or a peer device we have another application called Peer Application.

This peer application  have a common code base with the application under test and is using the same host stack but we are using it at lower level your controller stack.



This is why we don't use your host stack.

Now on our application we are using the privacy feature and the generation of the resolvable private address is delegated to the controller stack by setting the advertising parameter (0x2006) with 0x03 for own_address_type.



This explain why in our case the resolvable private address is gnerated into the controller stack.

using the command in itself results in a race condition -> The returned address may already be outdated when read by the application.

You have right if it reads at not the right time.

We are reading the resolvable private address while we are advertising and the address is checked against the addres we receive with a connection complete event.

Beside that the rpa refresh timer is pretty high around 20 minutes and we dont trigger any refresh.

Then we are pretty sure that the address is the same.

If it's really not possible we need to change our tests to test that the address is resolvable with the corresponding IRK in fact we dont really care that the address received is exactly the one we expect.

This will require quiet a lot of effort on our side it's why I am asking if there is a way to get this rpa.

[AHaug]

Thank you for explaining. I've relayed it to the developers for discussion w.r.t both feature request or if we have any solution for this. I'll keep you updated when I hear back from them

Kind regards;
Andreas

[AHaug]

Hi again,

Here's an update:

As we've concluded already we currently do not support the feature, but we have added the feature request and PMT is aware of the request so it's reached high up. Furthermore they've stated that at the moment we do not have an ETA of this, but it would be useful to know how urgent the request for support is so we can add this information to the internal information for the feature request. 

I were also told to mention that in addition to the upcoming NCS v2.7.0 we have planned 2 additional SDK releases for 2024. The question is if we complete the feature for the first of these, or if will be in the second. The feature will likely be available in main before an official release (I'll add the PR in a comment here when we get there) if you want to do testing as soon as it gets into the SDK.

Please let me know about the urgency and I'll bring that information back to the discussion

Kind regards,
Andreas