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

[owensc84]

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_testno_vscodeesp-
idf-v4.0.1
Checking Python dependencies...
Python requirements from c:eds\call_light\idf_testno_vscodeesp-idf-v4.0.1req
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_testno_vscodeesp-idf-v4
.0.1examples\bluetoothesp_ble_mesh\ble_mesh_node\onoff_server
Executing "winpty C:\Users\owens\AppData\Local\Programs\Python\Python37python.e
xe c:eds\call_light\idf_testno_vscodeesp-idf-v4.0.1\tools/idf_monitor.py -p C
OM4 -b 115200 c:eds\call_light\idf_testno_vscodeesp-idf-v4.0.1examples\bluet
oothesp_ble_mesh\ble_mesh_node\onoff_serverbuild\onoff_server.elf -m 'C:\Users
\owens\AppData\Local\Programs\Python\Python37python.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.)

sdkconfig_elf.zip

[Alvin1Zhang]

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

[Campou]

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]

@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]

Hi @owensc84

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

Thanks.

[Campou]

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]

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

[owensc84]

@Campou the patch appears to work, thanks!

[chegewara]

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

[Campou]

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]

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