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

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
  • Hi, 

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

    I believe it should be possible but I will have to ask the Mesh team to verify this statement and if we have any configurations that allows for this. As for the config you're, the CONFIG_BT_PRIVACY should enable/disable the use of Resolvable Private Addresses, which is only one type of random address. 

    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?

    How did you define and write the UUID? My guess is that the fault might be caused by how it is written in the code. Could you supply some code that illustrates how this is done in your application? If you're using a library for c-strings when defining the UUID, the string will be terminated when it reaches the first 0-byte in the string.

    Kind regards,
    Andreas

  • Hi,

    AHaug said:
    Is it possible to set MAC address from random to static for Mesh in nRF Connect SDK? 

    To force mesh use a static address they can set BT_MESH_DEBUG_USE_ID_ADDR option. For changing address, call bt_id_create before bt_enable with the required address. 

    Also, note that it is useful only for debugging purpose and not recommended to use it in actual products that are supposed to interop with other systems. If the app or such systems are made with assumption of mesh devices having static address, then such assumption won't hold good while dealing with third party devices.
    Kind regards,
    Andreas
  • Thank you for response Andreas.

    We want to use static MAC for troubleshooting our devices on the network. With static MAC we can identify our device (e.g. its location) and check for example corresponding RSSI values.

    Regarding UUID at the moment I am not completely sure, however this problem seems to appear in mesh sample projects, probably on /mesh/light sample.

  • Hi,

    In case your previous reply is a question for me to answer, could you please reformulate it into a question? Otherwise I am wondering if my previous reply has answered your question?

    Kind regards,
    Andreas

  • Your suggested way of achieving static MAC also requires Logging to be enabled. Previously I justified our need to have static MAC, is there any other way to do so, or maybe it will be added in the future (that we could use for produced devices)?

    And regarding UUID I did not find time yet to double check if issue appears on the sample project I mentioned above, however we derived our project from the sample and as far as I remember UUID was always with trailing zeroes.

Reply
  • Your suggested way of achieving static MAC also requires Logging to be enabled. Previously I justified our need to have static MAC, is there any other way to do so, or maybe it will be added in the future (that we could use for produced devices)?

    And regarding UUID I did not find time yet to double check if issue appears on the sample project I mentioned above, however we derived our project from the sample and as far as I remember UUID was always with trailing zeroes.

Children
  • Hi,

    Thank you for elaborating.

    mesh777 said:
    Your suggested way of achieving static MAC also requires Logging to be enabled. Previously I justified our need to have static MAC, is there any other way to do so, or maybe it will be added in the future (that we could use for produced devices)?

    Unfortunately no. There are no other way of doing so without changing the Mesh stack, which in turn will require you to go through all qualification procedures on your own. As far as future plans goes, you will need to contact the Regional Sales Director for your region to get a proper answer. If you don't have their contact information, please send me a PM on Devzone and I will send it to you! 

    mesh777 said:
    And regarding UUID I did not find time yet to double check if issue appears on the sample project I mentioned above, however we derived our project from the sample and as far as I remember UUID was always with trailing zeroes.

    Noted. Could you update me on this if you find the time to double check? As far as I can see this is not the case in the mesh/light sample we provide. If we're to be able to answer this question we need more details such as a minimal sample including the trailing zeroes UUID or minimum some code snippets/screen shots showing that this is the case

    Kind regards,
    Andreas 

  • I double checked the bluetooth/mesh/light sample from v1.8.0 SDK.

    I programmed sample to nRF52840-DK board and opened nRF Mesh App on iPad. If I press plus symbol in the top right corner to show unprovisioned devices, I see Mesh Light device in the list with the following UUID: DD959590-E8BA-41DB-8000-000000000000. What does it mean and how to get rid of these zeroes?

  • Hi,

    Apologies for the late response. I've been out of office on business travel for the past few days and will be for the two next weeks as well. I will do my best to find a colleague to handle your case for that duration. 

    Kind regards,
    Andreas

Related