esp-idf: ESP32c3 BLE RPA (Privay) Address doesn't change (IDFGH-9564)

Answers checklist.

I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.1-dev-3778-g370e250072

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

esp32c3

Power Supply used.

USB

What is the expected behavior?

When advertising with an RPA addr type my ota ADDR should be a random rotating RPA addr.

What is the actual behavior?

The advertising address has the fixed value 7e:1e:1e:79:4f:f7. I’ve verified this is the physically transmitted address with nrf sniffer

7e:1e:1e:79:4f:f7 is an RPA with a constant prand rand part of 1e:1e:1e concatenated hash of ah(irk, 7e:1e:1e) == 79:4f:f7. Which makes sense based on irk setup here.

Why is rand part always the same? Why doesn’t it change. Nimble calls BLE_HCI_OCF_LE_SET_RPA_TMO here to setup 15 minute ttl.

Steps to reproduce.

examples/bluetooth/nimble/bleprph
set-target esp32c3
main/main.c line 197; ble_gap_adv_start(BLE_OWN_ADDR_RPA_PUBLIC_DEFAULT…
Observe the ADV_IND addr is 7e:1e:1e:79:4f:f7

I’ve mostly tested with undirected ext_adv, but had no luck with any configuration (adv or directed).

Does the ESP32c3 actually support controller based RPA generated addresses? Am i somehow supposed to seed prand?

Debug Logs.

Frame 1894: 58 bytes on wire (464 bits), 58 bytes captured (464 bits) on interface /tmp/wireshark_extcap_-dev-ttyACM1, id 0
Nordic BLE Sniffer
Bluetooth Low Energy Link Layer
    Access Address: 
    Packet Header: 0x2060 (PDU Type: ADV_IND, ChSel: #2, TxAdd: Random)
        .... 0000 = PDU Type: 0x0 ADV_IND
        ...0 .... = Reserved: 0
        ..1. .... = Channel Selection Algorithm: #2
        .1.. .... = Tx Address: Random
        0... .... = Reserved: 0
        Length: 32
    Advertising Address: 7e:1e:1e:79:4f:f7 (7e:1e:1e:79:4f:f7)
    Advertising Data
        Flags
        16-bit Service Class UUIDs
        Device Name: nimble-bleprph
        Tx Power Level
    CRC: 0x9acc59

More Information.

No response

About this issue

Original URL
State: closed
Created a year ago
Comments: 20 (2 by maintainers)

Most upvoted comments

@zhp0406, thanks for looking into this. Like @braiden mentioned above, the RPA timeout setting seems to be getting ignored for some reason. Regarding the initial address issue, the biggest problem for us is that when multiple devices using our firmware boot around the same time, they have conflicting addresses.

sorry for that,it will take some time for us to solve the issue(The initial address is always 7e:1e:1e:79:4f:f7). In the meantime, to avoid affecting your usage, you can set a different Identity Resolving Key (IRK) for each device. This way, the addresses will be different during the first initialization. Note: You can use the API *int ble_hs_pvcy_set_our_irk(const uint8_t irk) to set the IRK for each device.

zhp0406 on Sep 18, 2023

@braiden @achugbGL @devcexx 1-The initial address is always 7e:1e:1e:79:4f:f7 we will fix it.

2-The API to change the timeout to something shorter than 15 minutes didn’t work.

The issue has been fixed, and we are currently testing it. In the meantime, you can use the following library to address your problem. We will synchronize the update to the IDF as soon as possible.

Instructions for use: Replace the problem in esp-idf/components/bt/controller/lib_esp32c3_family/esp32c3/libbtdm_app.a with the file I provided to you.

lib version (29996e0) libbtdm_app.zip

zhp0406 on Sep 18, 2023