Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Join an existing mesh Network with a mesh provisioner (nrf mesh sdk)

Hi,

Is it possible to join an existing mesh network with a provisioner made on Nrf52840 (s140)  ?

I have used the provisioner example to make a provisioner which actually create a new mesh network. But after an "erase all" of the board, the provisioning data are lost and the board can't reconnect to the network because information are lost during the erase (logic).

Is there a way to extract the provisioning data and mesh network data from the board to use them later on an other board ?

My goal is to create a mesh network with a device, then store in a file all the information related to this network to be able later with another board to join this network and add new devices.

I have setup a serial connection to send data through the usb port to my computer so I could retrieve and return the data by this method.

I know that this is possible in the mobile application with the "export network" and "import network" functions but I can't reproduce the functionality with the mesh SDK.

Is this possible? If yes how?
Regards

Used sdk :

- nRF5_SDK_16.0.0_98a08e2

- nrf5_SDK_for_Mesh_v4.2.0_src

Board used :

- nrf52840 evaluation board

- nrf52832 evaluation board

Parents
  • Hi Neicureuil, 

    The easiest way of "exporting" the provisioner data to another board is to just do a hex dump of the flash content of the board (nrfjprog --readcode ). You can then use this hex file to flash on other board to access the network. 
    However doing that doesn't allow to have multiple provisioner at the same time and every time you provision a new node you would need to do a new hex dump. And that you would have only one firmware for all the provisioner. 

    A more advanced option is to only copy the specific data that need to be restored on a new board so that you can customized it to export and import. What you need to copy is : network key, application keys, device keys, the composition data of nodes.
    We don't have the code of doing that. You would need to study the code and send such data back to PC.

    I would suggest to go for option 1 if you don't need any extra requirement. If you don't want to clone the whole flash, you can think of only copy the flash area that the dsm store the database. This way you can customize the firmware, and only copy the database flash area. 

  • Hi,

    Thank for your response.

    Is there a way to copy the flash area without using "nrfjprog" because at the end, the goal is to put the code on a nrf52840 usb dongle which will be connected to a linux autonomous computer (maybe directly from the code).

  • Hi, 
    Then I think you need to study the code and see how the data is restored (read from flash) on every boot (in functino mesh_config_load() ).

    After that you can just read the data and send it to the Linux computer via UART/USB.  And on the new provisioner you can try to replace the mesh_config_load() with a function that you made with the data fed from the computer. 

  • Hi,

    I have successfully reload the 3 key (app, dev and net) and I'am now able to receive command's callbacks and device alive event from provisioned devices after a node reset.

    But I can't configure my device using the config model because the "dsm_address_handle_get" function return an "NRF_ERROR_NOT_FOUND".

    I think its because acutally I didn't reload the composition data of nodes. I looked at the code to try to extract and re-import the datas but I didn't understand how its works.

    Can you give me some advice to do that or is there a way to configure a device without these addresses (because the other models always work without) or is there a way to ask the devices for this information in order to reload them in memory ?

    Regards

  • Hei Neucureuil, 
    Have you added the addresses of the devices (the provisioned nodes) in to the dsm database ? You would need to call dsm_address_publish_add() to add the address(es), after that the call dsm_address_handle_get() should work .

  • Hi,

    No I haven't add the address to the dsm database because after a reset I don't know this address.

    This address is the device mesh uuid or another thing ? If another, can I get it by broadcasting some commands ?

    Regards

Reply Children
  • Hi Neicureuil, 
    The address here is the address that the provisioner assigned to the node (the unicast address). 
    If you have a look at the provisioner code when it handles NRF_MESH_PROV_EVT_COMPLETE event in prov_evt_handler() in provisioner_helper.c you can find the call when it add the address to the dsm database. 

  • Hi,

          case NRF_MESH_PROV_EVT_COMPLETE:
          {
            NRF_LOG_INFO("Provisioning completed received\n");
            m_prov_state = PROV_STATE_COMPLETE;
    
            /* After provisioning completes, add corresponding node's address and device key to
            local database */
            NRF_LOG_INFO("Adding device address, and device keys\n");
            ERROR_CHECK(dsm_address_publish_add(p_evt->params.complete.p_prov_data->address,
                                                &addr_handle));
            ERROR_CHECK(dsm_devkey_add(p_evt->params.complete.p_prov_data->address,
                                       m_provisioner.p_dev_data->m_netkey_handle,
                                       p_evt->params.complete.p_devkey,
                                       &devkey_handle));
    
            /* Bind the device key to the configuration server and set the new node as the active server. */
            ERROR_CHECK(config_client_server_bind(devkey_handle));
            ERROR_CHECK(config_client_server_set(devkey_handle, addr_handle));
    
            NRF_LOG_INFO("Addr: 0x%04x addr_handle: %d netkey_handle: %d devkey_handle: %d\n",
                  p_evt->params.complete.p_prov_data->address,
                  addr_handle,
                  m_provisioner.p_dev_data->m_netkey_handle,
                  devkey_handle);
    
            break;
          }

    This is the NRF_MESH_PROV_EVT_COMPLETE  event from the provisioner.

    But in this example, its require the dev key of the provisioned device (p_evt->params.complete.p_devkey) but when I want to reload the mesh, I only have the device unicast address recovered by the alive event of the health model.

    So, how can i get the device dev key from the alive event to re add the node to the dsm database.

    Regards

  • Hi, 
    Device key is the secret key between the provisioner and the particular node. So a new node coming to the network shouldn't be able to get this key.


    You need to export the device keys out of the original provisioner. Then import it to the new provisioner. 

  • Hi,

    Thanks for the answer.

    I ask even if I think it is not possible, but is there no way to force a new exchange (and generation) of this secret key without knowing the old one ?

    Also, when I reload a mesh network (by reloading the 3 keys), the provisioner doesn't know the devices anymore (this is normal because I didn't reload the provisioning data) However, it still receives the events alives of the health model and when I send a model command, the devices of the network receive it and interpret it but I have no acknowledgement but after 5 mins, without changing anything, the acknowledgements come back for new commands.
    My question is why I don't receive any when the network reloads but with time, I end up receiving some? Is there any way to speed up this waiting process?

    Regards

  • Hi,

    No it's not possible to update the new device key as far as I know. Otherwise any node in the network would be capable of modifying other nodes in the network. 


    Regarding what you described about the device works after a while, it could be related to IV index updating. So when your device is out of sync with the network (for example inactive for too long, or newly join the network as you are doing now), the IV index might not be the most updated and it won't be able to communicate. It would then need to wait for Secure Network Beacon to sync the IV index after that it would be able to communicate normally. The Secure Network Beacon is broadcasted periodically by all nodes. 

Related