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.

[ibex]

Hi Andreas

Any news regarding this ticket?

Kind regards,
Matthias

[AHaug]

Ahoy there, long time no see.

I will hunt down the internal ticket and ping the people tagged in it for a status. Apologies for the radio silence.

Kind regards,
Andreas

[ibex]

Many thanks!

Kind regards,
Matthias

[AHaug]

Matthias, can you confirm if this description of the use case still matches the request?

• Use cases: They want to know what resolvable private address the local advertiser is using.
• Environment: nRF5340 using their own Bluetooth host utilizing controller-based privacy (which the zephyr host (usually) does not)
• Workaround: Have another scanner nearby scanning for advertisers. Communicate the address over some other transport

Kind regards,
Andreas

[ibex]

Hi Andreas,

positiv for the first two points. Regarding the third point:

We scan the different advertisers and if we found an advertiser advertising with an RPA address which can be resolved with the IRK of the advertiser then we use this RPA address as the address of the advertiser.

Before we were reading the local RPA of the advertiser and then expect that the advertiser advertise with this address. We also used the RPA address to initiate a connection.

Kind regards,
Matthias

[AHaug]

Thank you for verifying, I've relayed this information to the internal ticket.

Kind regards,
Andreas

[AHaug]

Hi again,

I would also like to inform you to reach out to your regional sales manager w.r.t querying for a status for this and priority and share your wishes for this feature through them as well. 

Kind regards,
Andreas

[ibex]

Hi Andreas,

thanks for the heads up. I guess this means "not any time soon" then..
Please keep us posted in case there is any update.

Kind regards,
Matthias

[AHaug]

Well yeah.. Unfortunately it looks like it's been "not anytime soon" for quite a while and since action hasn't sped up since the resurrection I can't promise you any more escalation than what can be given through sales.

But the internal case shouldn't be closed without giving a notice here, so there's that at least

Kind regards,
Andreas