espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.44k stars 7.25k forks source link

CONFIG_BT_NIMBLE_HOST_BASED_PRIVACY not found when upgrading to ESP 5.1.2 (IDFGH-11967) #13042

Closed hunterramp closed 5 months ago

hunterramp commented 8 months ago

Answers checklist.

General issue report

We recently updated our codebase to use the latest esp-idf version (5.1.2) and the CONFIG_BT_NIMBLE_HOST_BASED_PRIVACY was removed from the sdkconfig file. We can't seem to locate it in the menu config in order to enable and use host based privacy.

Are there any tricks to enabling this option? Any help would be greatly appreciated!

We are using the ESPS3 chip.

Edit:

The only workaround we have found was to modify the esp-idf/components/bt/host/nimble/Kconfig.in file to specify IDF_TARGET_ESP32S3 instead of IDF_TARGET_ESP32 in the BT_NIMBLE_HOST_BASED_PRIVACY section.

rahult-github commented 8 months ago

Hi @hunterramp ,

ESP32S3 chipset has controller based privacy enabled by default. This is the reason , the flag you mentioned ( which basically attempts to address host based privacy support) is not enabled. You should keep this flag disabled for ESP32S3 ( or any other chipset apart from ESP32) .

hunterramp commented 8 months ago

Hi @rahult-github, thanks for your response. Without the CONFIG_BT_NIMBLE_HOST_BASED_PRIVACY option enabled, we run into build errors when calling functions like ble_hs_pvcy_rpa_config. These errors are caused by lines like this in the nimble component: https://github.com/espressif/esp-nimble/blob/20d3df32c2b569ed51010a396167d4b097fac7ca/nimble/host/include/host/ble_hs_pvcy.h#L31

rahult-github commented 8 months ago

Hi @hunterramp ,

Enabling the flag should not cause any compilation issue. I gave a quick try on 5.1 release branch by forcing that flag to be enabled. Attached is compilation log and sdkconfig used for compiling bleprh example for s3

s3_compile_log.txt sdkconfig.txt

so, is there any other modification done at your end ? But anyways, even if we get the compilation working, enabling that flag for s3 will result in functional failures ( scenarios like controller will already resolve a address which host will try to resolve again and vice versa). So you can instead leverage controller privacy feature is my suggestion.

rahult-github commented 8 months ago

Hi @hunterramp ,

Sorry i misread your comment.

Without the CONFIG_BT_NIMBLE_HOST_BASED_PRIVACY option enabled, we run into build errors when calling functions like ble_hs_pvcy_rpa_config

This is expected. The functionality is under the flag and if flag is disabled, off course the mentioned functions / APIs will not be compliled.

hunterramp commented 8 months ago

Hi @hunterramp ,

Enabling the flag should not cause any compilation issue. I gave a quick try on 5.1 release branch by forcing that flag to be enabled. Attached is compilation log and sdkconfig used for compiling bleprh example for s3

s3_compile_log.txt sdkconfig.txt

so, is there any other modification done at your end ? But anyways, even if we get the compilation working, enabling that flag for s3 will result in functional failures ( scenarios like controller will already resolve a address which host will try to resolve again and vice versa). So you can instead leverage controller privacy feature is my suggestion.

@rahult-github, thanks again for responding so quickly! The problem we were facing was there was no way to actually enable the flag in the sdkconfig file. We tried adding it via the menu config, but the host based privacy option was not there. We tried adding it manually, but it would get deleted as soon as we built again.

I believe the problem is the esp-idf/components/bt/host/nimble/Kconfig.in file I mentioned above, where it depends on IDF_TARGET_ESP32 (which we do not have defined in our sdkconfig), instead of IDF_TARGET_ESP32S3.

rahult-github commented 8 months ago

Hi @hunterramp ,

I believe the problem is the esp-idf/components/bt/host/nimble/Kconfig.in file I mentioned above, where it depends on IDF_TARGET_ESP32 (which we do not have defined in our sdkconfig), instead of IDF_TARGET_ESP32S3.

So , this is not a problem. Because, this flag should not be enabled for the mentioned chipset when using the ESP-IDF . And hence the implementation includes the modification of Kconfig with inbuilt dependancy to ensure a user do not mistakenly enable the flag.

May i know what is to be achieved in your use case for which enabling the flag is important for esp32s3 ?

rahult-github commented 7 months ago

Hi @hunterramp , any update ?

AdamHickerson commented 6 months ago

Hi @rahult-github, I am supporting @hunterramp on this. I don't quite understand, are you saying that this feature has been removed/deprecated for S3? We had been using IDF v4.4.4 with this flag enabled, and using the RPA feature. We are still able to use the RPA feature with IDF v5.1.2 but with @hunterramp fix. Was it intentionally removed/disabled, and can you comment on what doesn't work?

rahult-github commented 6 months ago

Hi @AdamHickerson ,

ESP32S3 chipset has controller based privacy enabled by default.

Since chipset has controller based privacy, using host based privacy along with controller based privacy would lead to undefined behavoiurs and can cause functionality break.

So, this flag's usage was corrected such that it should be enabled only for ESP32 and not for rest of the chips.

With the flag disabled, do you observe any issue with address resolution ?

AdamHickerson commented 6 months ago

What's the method to enable RPA on the ESP32-S3? Can you give an example? We can run that to answer the question

rahult-github commented 6 months ago

Hi @AdamHickerson

What's the method to enable RPA on the ESP32-S3? Can you give an example? We can run that to answer the question

Please try run bleprph example from IDF. Make sure CONFIG_EXAMPLE_RESOLVE_PEER_ADDR and CONFIG_EXAMPLE_BONDING is enabled to ensure IRK gets generated and distributed. ( which is anyways needed irrespective of host / controller based privacy) .

This should let you test address resolution functionality . Connect from remote with random address . Ensure SMP is done. For this, you can try to either bond OR attempt encryption . Once authentication is completed , let remote disconnect. Now if remote attempts connection with a different address, you should observe the address getting resolved. This is because, when the previous connection shared the IRK, the controller has the key / address combination, which now gets used and address is resolved on basis of it.

rahult-github commented 5 months ago

Closing the issue since already explained the reason for this .