Bluetooth: Host: get RPA address without changing it for scanners

[koffes]

Issue When creating an advertiser, we can use the following code to get the RPA without changing it:

bt_le_ext_adv_get_info(ext_adv, &ext_adv_info);
print(ext_adv_info.addr)

There is also a callback option to catch an RPA timeout.

However, there is no such API to get the RPA for a scanner. The only option is to call bt_le_oob_get_local, but this changes the RPA.

Describe the solution you'd like It would be be beneficial to have a similar API which does not change the RPA when called. In addition, it would be great to have some callback from the scanner as well when an RPA timeout has occured.

[koffes]

FYI @Thalley :)

[Thalley]

Effectively what this should do, is to get the bt_dev.random_addr

[hermabe]

There is also a usecase for this when creating a connection to a PAwR sync/scanner. The address may change after a timeout or when enabling some other role so it is difficult to get the actual address stored in the controller (set with the LE Set Random Address command) which you need to connect to.

[Thalley]

There is also a usecase for this when creating a connection to a PAwR sync/scanner. The address may change after a timeout or when enabling some other role so it is difficult to get the actual address stored in the controller (set with the LE Set Random Address command) which you need to connect to.

In the case where you create a connection, I think you can use bt_conn_get_info an then get the bt_conn_info.le.local address, which I think holds the RPA being used to initialize the connection

[hermabe]

There is also a usecase for this when creating a connection to a PAwR sync/scanner. The address may change after a timeout or when enabling some other role so it is difficult to get the actual address stored in the controller (set with the LE Set Random Address command) which you need to connect to.

In the case where you create a connection, I think you can use bt_conn_get_info an then get the bt_conn_info.le.local address, which I think holds the RPA being used to initialize the connection

That is only possible after the connection is established. This could not be used in the following case:

• PAwR advertiser starts
• PAwR sync scans for advertisements and syncs to it
• PAwR advertiser sends a connect request to the sync including the syncs configured address.

In this case it is nice to know or be able to update the address configured on the sync side.

[Thalley]

That is only possible after the connection is established. This could not be used in the following case:

Incorrect: bt_conn_get_info can be called in the connecting state too. As soon as the conn object pointer have been retrieved, you can get the info of it.

[hermabe]

That is only possible after the connection is established. This could not be used in the following case:

Incorrect: bt_conn_get_info can be called in the connecting state too. As soon as the conn object pointer have been retrieved, you can get the info of it.

On the sync side the connection object is allocated when the connection complete event is received.

[Thalley]

That is only possible after the connection is established. This could not be used in the following case:

Incorrect: bt_conn_get_info can be called in the connecting state too. As soon as the conn object pointer have been retrieved, you can get the info of it.

On the sync side the connection object is allocated when the connection complete event is received.

Oh, so you don't get the conn object when you request the connection, like you'd "normally" do? That's a shame, but yes, then that is also a use-case for this request :)