• State Not Answered
  • Replies 13 replies
  • Subscribers 68 subscribers
  • Views 2376 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 294532
Options

NCS: Setting MAC address to static for Mesh; UUID last bytes are zeroes

mesh777

1. Is it possible to set MAC address from random to static for Mesh in nRF Connect SDK? 

CONFIG_BT_PRIVACY=n and CONFIG_BT_SETTINGS=y seems does not change the behavior.

2. We have an issue with UUID, last bytes are zeroes in default configuration. Is it a bug or how to configure SDK to avoid this?

Parents
  • 0

    Hi,

    I have looked into why UUIDs end in 8000-000000000000.

    In short the UUID is generated from the device ID, which for nRF SoCs is 8 bytes long. The resulting UUID is therefore the device ID with byte 6 modified to comply with the UUID specification, followed by the 8000-000000000000 sequence.

    I have notified the mesh team and am awaiting their feedback.

    Regards,
    Terje

  • 0 in reply to tesc

    Hi,

    The resulting UUID is not necessarily "wrong", even though it looks a bit strange because of the way it is generated. Do you have a hard requirement on the UUID not ending in the 8000-000000000000 sequence? I assume the rest of the UUID should be enough for identifying the device, as it is based on the device ID of the SoC.

    Regards,
    Terje

  • 0 in reply to tesc

    We want to have more commonly looking number. How can I change it?

  • 0 in reply to mesh777

    Hi,

    You would have to change the code for bt_mesh_dk_prov_init() in dk_prov.c.

    In particular, you should fill the missing bytes of dev_uuid (bytes 8 through 15) before the following lines:

    	dev_uuid[6] = (dev_uuid[6] & BIT_MASK(4)) | BIT(6);
	dev_uuid[8] = (dev_uuid[8] & BIT_MASK(6)) | BIT(7);

    Those two lines change some of the bits, for compliance with RFC-4122.

    Please note that the UUID should stay the same for the same device, so the UUID generation should be deterministic. My main suggestion would be to use the DEVICEADDR, from FICR, which is the 48 bit default Bluetooth MAC address of the SoC. The rest of the UUID consists of the device ID, which is also taken from FICR. That leaves two bytes still zero, which you can either leave zero or fill with some other fixed, read-from-persistent-memory or reproducible value.

    Regards,
    Terje

Reply
  • 0 in reply to mesh777

    Hi,

    You would have to change the code for bt_mesh_dk_prov_init() in dk_prov.c.

    In particular, you should fill the missing bytes of dev_uuid (bytes 8 through 15) before the following lines:

    	dev_uuid[6] = (dev_uuid[6] & BIT_MASK(4)) | BIT(6);
	dev_uuid[8] = (dev_uuid[8] & BIT_MASK(6)) | BIT(7);

    Those two lines change some of the bits, for compliance with RFC-4122.

    Please note that the UUID should stay the same for the same device, so the UUID generation should be deterministic. My main suggestion would be to use the DEVICEADDR, from FICR, which is the 48 bit default Bluetooth MAC address of the SoC. The rest of the UUID consists of the device ID, which is also taken from FICR. That leaves two bytes still zero, which you can either leave zero or fill with some other fixed, read-from-persistent-memory or reproducible value.

    Regards,
    Terje

Children
No Data
Related