Re: bt_mesh_init error codes

Martin Woolley <mwoolley@...>

Johan, thanks a bunch for your comprehensive reply. You're correct that I started with the mesh_demo configuration and probably "borrowed" code from elsewhere as well, so that explains how I arrived here. The information on POSIX error numbers really helps... as I get more familiar with the code, hopefully I too will now be able to find where errors are being generated and deduce the reason.

I'll give this another try shortly!

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@...]
Sent: 23 February 2018 19:00
To: Martin Woolley <mwoolley@...>
Cc: zephyr-users@...
Subject: Re: [Zephyr-users] bt_mesh_init error codes

Hi Martin,

On Fri, Feb 23, 2018, Martin Woolley wrote:
Hi, where can I find return codes for bt_mesh_init (and other
functions for that matter). I know a negative value means it failed
but I was hoping for some thing that provides a description of
specific return codes. I’m getting -35 from bt_mesh_init. It could be
because it’s Friday and been a long week but there may be a better
explanation 😊

bt_mesh_init failed with err -35
Negative 'int' type errors in Zephyr generally map to POSIX error numbers. E.g. 35 is the same as ENOTSUP. Looking through the possible code paths that bt_mesh_init() triggers, it seems likely that the following snippet in bt_pub_key_gen() (in hci_core.c) is at fault:

* We check for both "LE Read Local P-256 Public Key" and
* "LE Generate DH Key" support here since both commands are needed for
* ECC support. If "LE Generate DH Key" is not supported then there
* is no point in reading local public key.
if (!(bt_dev.supported_commands[34] & 0x02) ||
!(bt_dev.supported_commands[34] & 0x04)) {
BT_WARN("ECC HCI commands not available");
return -ENOTSUP;

Btw, you should enable CONFIG_BT_DEBUG_LOG=y since that would have given you the error message above (assuming this code path is at fault).
Adding the following to your configuration should make the issue go


I suspect you arrived here because you started off with the mesh_demo configuration. The mesh_demo app does self-provisioning and as such doesn't need ECDH. Now you've apparently enabled the provisioning protocol, but not made sure that you have ECDH available. This needs to be explicitly enabled, since in split host & controller situations (where the controller is on a separate core) the controller may be providing the ECDH HCI commands, in which case ECDH support on the host side is not needed (beyond being able to send these HCI commands).


Join to automatically receive all group messages.