bt_mesh_init error codes


Martin Woolley <mwoolley@...>
 

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

 

Thanks

 

Martin


Johan Hedberg
 

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
away:

CONFIG_BT_TINYCRYPT_ECC=y

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).

Johan


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@intel.com]
Sent: 23 February 2018 19:00
To: Martin Woolley <mwoolley@bluetooth.com>
Cc: zephyr-users@lists.zephyrproject.org
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
away:

CONFIG_BT_TINYCRYPT_ECC=y

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).

Johan