ESP32 BLE mesh example fails to provision (IDFGH-3365)

owensc84 commented 4 years ago

Environment

Development Kit: ESP32-DevKitC
Kit version (for WroverKit/PicoKit/DevKitC): v4
Module or chip used: ESP32-WROOM-32D
IDF version (run git describe --tags to find it): v4.0
Build System: CMake|idf.py
Compiler version (run xtensa-esp32-elf-gcc --version to find it): xtensa-esp32-elf-gcc.exe (crosstool-NG esp-2019r2) 8.2.0
Operating System: Windows
(Windows only) environment type: Plain Command Prompt
Using an IDE?: vscode extension
Power Supply: USB

Problem Description

I am unable to provision the BLE mesh tutorial example project with the nrf mesh mobile application. The link to the tutorial to follow.

nRF Mesh v2.3.0

Tutorial link

Expected Behavior

Provisioning is successful

Actual Behavior

Provisioning fails with a message on the phone application "Prohibited!" See attached image

Steps to reproduce

Build the aforementioned example project, flash the project, attempt to provision via the nRF mesh phone app.

Code to reproduce this issue

Code found here.

Debug Logs

$ idf.py monitor Setting IDF_PATH environment variable: c:\eds\call_light\idf_test\no_vscode\esp- idf-v4.0.1 Checking Python dependencies... Python requirements from c:\eds\call_light\idf_test\no_vscode\esp-idf-v4.0.1\req uirements.txt are satisfied. Executing action: monitor Choosing default port b'COM4' (use '-p PORT' option to set a specific serial por t) Running idf_monitor in directory c:\eds\call_light\idf_test\no_vscode\esp-idf-v4 .0.1\examples\bluetooth\esp_ble_mesh\ble_mesh_node\onoff_server Executing "winpty C:\Users\owens\AppData\Local\Programs\Python\Python37\python.e xe c:\eds\call_light\idf_test\no_vscode\esp-idf-v4.0.1\tools/idf_monitor.py -p C OM4 -b 115200 c:\eds\call_light\idf_test\no_vscode\esp-idf-v4.0.1\examples\bluet ooth\esp_ble_mesh\ble_mesh_node\onoff_server\build\onoff_server.elf -m 'C:\Users \owens\AppData\Local\Programs\Python\Python37\python.exe' 'C:/eds/call_light/idf _test/no_vscode/esp-idf-v4.0.1/tools/idf.py'"... --- idf_monitor on COM4 115200 --- --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:6984 load:0x40078000,len:14076 load:0x40080400,len:4304 entry 0x400806e8 I (71) boot: Chip Revision: 1 I (71) boot_comm: chip revision: 1, min. bootloader chip revision: 0 I (39) boot: ESP-IDF v4.0.1-dirty 2nd stage bootloader I (39) boot: compile time 15:21:04 I (39) boot: Enabling RNG early entropy source... I (44) boot: SPI Speed : 40MHz I (48) boot: SPI Mode : DIO I (52) boot: SPI Flash Size : 2MB I (56) boot: Partition Table: I (60) boot: ## Label Usage Type ST Offset Length I (67) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (74) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (82) boot: 2 factory factory app 00 00 00010000 00100000 I (89) boot: End of partition table I (94) boot_comm: chip revision: 1, min. application chip revision: 0 I (101) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x2bf00 (17

I (1118) onoff_server: ESP_BLE_MESH_PROV_REGISTER_COMP_EVT, err_code 0 I (1128) onoff_server: ESP_BLE_MESH_NODE_PROV_ENABLE_COMP_EVT, err_code 0 I (1128) onoff_server: BLE Mesh Node initialized I (21198) onoff_server: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-GATT W (23968) BLE_MESH: bt_mesh_attention, No Health Server context provided

Other items if possible

[x] sdkconfig file (attach the sdkconfig file from your project folder)
[x] elf file in the build folder (note this may contain all the code details and symbols of your project.)
[ ] coredump (This provides stacks of tasks.)

Screenshot_20200523-154438 sdkconfig_elf.zip

Alvin1Zhang commented 4 years ago

@owensc84 Thanks for the bug report and letting us know about this. We will look into.

Campou commented 4 years ago

Hi @owensc84

Thanks for reporting this.

Using the nRF Mesh Android Apps (version 2.3.0 & 2.2.0), I failed to provision the device running onoff_server example.

Then I tried with the version 2.1.3, it works fine. Also tried with the latest iOS nRF Mesh App, it works fine too.

I'm not sure why the latest nRF Mesh Android App failed to handle the public key from esp32, also I've noticed that this issue has been submitted in the Android-nRF-Mesh-Library Issues, we can follow this issue for further updates.

Thanks.

owensc84 commented 4 years ago

@Campou, thanks for the response.

Is this a problem with the ESP32 sdk or the nRF-Mesh app? From the linked nRF-Mesh bug report it appears to be a nRF-Mesh app issue. What concerns me is I am unable to provision the on-off example with other vendor apps as well, they all fail at one place or another. The ST mesh app seems to provision, but crashes when attempting to access an element.

I am able to provision the "nimble" example without issue, this example is found here.

Campou commented 4 years ago

Hi @owensc84

Thanks for the info. Will look into this and get back to you ASAP.

Thanks.

Campou commented 4 years ago

Hi @owensc84

I have found the root cause. The onoff_server uses 23 as the default MTU size, which causes the failure of the provisioning procedure on the App side. After changing the MTU size to 69, the provisioning procedure is completed successfully.

Please apply this patch to have a try set-mtu-size-to-69.zip. Will update this info to the Android-nRF-Mesh-Library Issues.

Thanks.

owensc84 commented 4 years ago

@Campou, Thank you I will give the patch a try.

owensc84 commented 4 years ago

@Campou the patch appears to work, thanks!

chegewara commented 4 years ago

Is not that ble mesh specs requires min MTU size to be 69?

Campou commented 4 years ago

Hi @chegewara

From the spec, it says The Provisioning Server should support an ATT_MTU size equal to or larger than 69 octets to accommodate the longest known Provisioning message. Since it uses should, so 69 is a recommendation, which can avoid segmentation and reassembly in the proxy protocol.

Using the default MTU size 23 here should not cause any problem, and IMO, a GATT client should try to exchange the MTU size before any further GATT procedures. Also I've noticed that nRF Mesh App is following this procedure, so maybe some other things went wrong.

Thanks.

Alvin1Zhang commented 4 years ago

Thanks for reporting, feel free to reopen if the issue still happens, or please help file a new ticket for new issue, thanks.

chegewara commented 7 months ago

Hi, i know this is old topic, but i would like to update some info and maybe ask espressif to clarify. From Mesh Profile 1.0.1

7.2.2.2.4 ATT_MTU
The server should support an ATT_MTU size equal to or larger than 33 octets to be able to pass the
content of a full Proxy PDU (see Section 6.5).

https://www.bluetooth.com/specifications/specs/mesh-profile-1-0-1/

Thanks

espressif / esp-idf