The default generated Device UUID in SDK For Mesh v4.0.0 uses wrong endianess.
From the Mesh Profile v1.0.1, section "3.10.3 Device UUID"
"To decrease the complexity of deploying nodes, a unique Bluetooth BD_ADDR is not required for mesh
operations. Instead, each node shall be assigned a 128-bit UUID known as the Device UUID. Device
manufacturers shall follow the standard UUID format as defined in [8] and generation procedure to ensure
the uniqueness of each Device UUID."
Reference [8] is RFC 4122 which states
"In the absence of explicit application or presentation protocol
specification to the contrary, a UUID is encoded as a 128-bit object,
as follows:
The fields are encoded as 16 octets, with the sizes and order of the
fields defined above, and with each field encoded with the Most
Significant Byte first (known as network byte order)."
Thus the standard specifies that the encoding should use network byte order.
The following is the log from a devkit using the default UUID generated by nrf_mesh_configure_device_uuid_reset() and printed using mesh_app_uuid_print().
<t: 5746>, mesh_app_utils.c , 65, Device UUID (raw): FCB3899CA721B543BF3A031D14979191 <t: 5750>, mesh_app_utils.c , 66, Device UUID : 9C89B3FC-21A7-43B5-BF3A-031D14979191
The UUID string representation looks fine. The third field (43B5) have the most significant 4 bits set to the value 4 which is expected as the default UUID is using version 4, "randomly generated".
The raw data doesn't look correct as the first three fields have different endianess.
Looking at the Mesh Beacon and Mesh Provisioning Service Data in Wireshark gives the following data matching the (raw) output in the log above.
Mesh Beacon Device UUID: fcb3899c-a721-b543-bf3a-031d14979191 Service Data: fcb3899ca721b543bf3a031d149791910000
In the string representation of the UUID from Wireshark the version is "b" (11) which doesn't exist in RFC 4122.
Looking at the example data provided in the Mesh Profile v1.0.1, section "8.4.1 Unprovisioned device beacon (without URI)" it's possible to find an example Device UUID.
Device UUID: 70cf7c9732a345b691494810d2e9cbf4
Here the third field (time_hi_and_version octet 6-7) are 45b6. Here the version is 4 which is expected. If this example was in little endian the version would be "b" which doesn't exist in the RFC 4122.
The following patch adjusts the placement of the version bits in the UUID and updates the print function so that it matches what other tools show.
diff --git a/examples/common/src/mesh_app_utils.c b/examples/common/src/mesh_app_utils.c
index b64880d..372da0a 100644
--- a/examples/common/src/mesh_app_utils.c
+++ b/examples/common/src/mesh_app_utils.c
@@ -40,6 +40,7 @@
#include "nrf.h"
#include "nrf_error.h"
#include "log.h"
+#include "utils.h"
/** Structure for pasring UUID */
typedef struct __attribute((packed))
@@ -64,7 +65,7 @@ void mesh_app_uuid_print(const uint8_t * p_uuid)
UNUSED_VARIABLE(p_format);
__LOG_XB(LOG_SRC_APP, LOG_LEVEL_INFO, "Device UUID (raw)", p_uuid, NRF_MESH_UUID_SIZE);
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Device UUID : %08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X\n",
- p_format->time_low, p_format->time_mid, p_format->time_hi_version,
+ LE2BE32(p_format->time_low), LE2BE16(p_format->time_mid), LE2BE16(p_format->time_hi_version),
p_format->clock_seq_hi_reserved, p_format->clock_seq_low,
p_format->node[0], p_format->node[1], p_format->node[2], p_format->node[3],
p_format->node[4], p_format->node[5]);
diff --git a/mesh/core/src/nrf_mesh_configure.c b/mesh/core/src/nrf_mesh_configure.c
index 0da64cf..ce054e2 100644
--- a/mesh/core/src/nrf_mesh_configure.c
+++ b/mesh/core/src/nrf_mesh_configure.c
@@ -50,8 +50,9 @@
typedef struct __attribute((packed))
{
- uint64_t uuid_00_59 : 60;
+ uint64_t uuid_00_51 : 52;
uint64_t version : 4;
+ uint64_t uuid_56_63 : 8;
uint64_t uuid_64_67 : 4;
uint64_t uuid_68_69 : 2;
As the rest of the UUID is random it doesn't make any sense to make any adjustments to that data.
Thanks.
