You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
5.3
Espressif SoC revision.
ESP32
Operating System used.
Windows
How did you build your project?
Command line with CMake
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32
Power Supply used.
USB
What is the expected behavior?
I have a BLE-Mesh bulb that has static OOB authentication set, but also accepts NO_OOB. In the "Provisioning Capabilities" it correctly advertises that it has Static OOB (0x1).
As I have not set the Static OOB in the ESP32 ESP-IDF provisioner, I would expect that the authentication to method in the "Provisioning Start" packet to be none, and for the provisioning to succeed.
What is the actual behavior?
provisioning fails with the remote device ( bulb ) returning error code 4.
The ESP-IDF provisioner ask for Static OOB, but fills the auth data with 0 ( copied from the zero length data in the provisioner context ), but the remote device uses its OOB data, and authentication fails.
Steps to reproduce.
Use a bulb that is marked with "Works with Alexa" which typically is pre-provisioned with a static OOB data for secure paring with the assistant.
Use and ESP32x with example provisioner, and the uuid 'match' set to either none, or match the UUID of the device.
where it checks if it could use static OOB, check that there is configured static OOB data in the context:
if (oob_type & BIT(PROV_STATIC_OOB_AVAILABLE) **&& prov_ctx.static_oob_len > 0**) {
/* if static oob is valid, just use static oob */
Also it would be useful to be able to remove static OOB data when switching between different devices with different authentication needs.
Currently bt_mesh_provisioner_set_static_oob_value checks for length > 0
The text was updated successfully, but these errors were encountered:
Sorry this has sat around for an extraordinary long time without further feedback.
I don't understand your point. Once a node sets the static OOB bit in the provisioning capabilities, the provisioner should obtain the public key using the static OOB method. If the provisioning fails because the application hasn't set the static OOB, it should be an issue with the application settings, not with the ble mesh protocol.
Answers checklist.
IDF version.
5.3
Espressif SoC revision.
ESP32
Operating System used.
Windows
How did you build your project?
Command line with CMake
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32
Power Supply used.
USB
What is the expected behavior?
I have a BLE-Mesh bulb that has static OOB authentication set, but also accepts NO_OOB. In the "Provisioning Capabilities" it correctly advertises that it has Static OOB (0x1).
As I have not set the Static OOB in the ESP32 ESP-IDF provisioner, I would expect that the authentication to method in the "Provisioning Start" packet to be none, and for the provisioning to succeed.
What is the actual behavior?
provisioning fails with the remote device ( bulb ) returning error code 4.
The ESP-IDF provisioner ask for Static OOB, but fills the auth data with 0 ( copied from the zero length data in the provisioner context ), but the remote device uses its OOB data, and authentication fails.
Steps to reproduce.
Use a bulb that is marked with "Works with Alexa" which typically is pre-provisioned with a static OOB data for secure paring with the assistant.
Use and ESP32x with example provisioner, and the uuid 'match' set to either none, or match the UUID of the device.
Provisioning fails
Debug Logs.
No response
More Information.
In https://github.com/espressif/esp-idf/blob/master/components/bt/esp_ble_mesh/core/prov_pvnr.c#L1280
static void prov_capabilities(struct bt_mesh_prov_link *link, struct net_buf_simple *buf)
where it checks if it could use static OOB, check that there is configured static OOB data in the context:
Also it would be useful to be able to remove static OOB data when switching between different devices with different authentication needs.
Currently bt_mesh_provisioner_set_static_oob_value checks for length > 0
The text was updated successfully, but these errors were encountered: