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

[neicureuil]

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

[Hung Bui]

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. 

[neicureuil]

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

[Hung Bui]

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. 

[neicureuil]

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

[Hung Bui]

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. 

[neicureuil]

Hi,

Thanks for all this informations.

Can I send from the provisioner a mesh command that force a new Secure Network Beacon ?

If its not possible, can I change the periodic delay of this beacon (for example at the first provisioning) ?

Regards

[Hung Bui]

Hi, 

Please refer to the mesh spec, look for "Beacon Interval" in 3.9.3.1 . The implementation in our code is in update_beacon_interval(). But modifying this may cause an issue for qualification. 
I don't think it would take a few minutes to receive a beacon. So it's quite strange that it took 5 minutes in your case. How many nodes in the network when you tested ? Please try with at least 3-4 nodes. 

[neicureuil]

Hi,

In my tests I have 5 nodes in my network.

I have also test with one, two and three and got the same issue.

Also, I have forgot to mention that the nodes took an average of 5 mins before interpreting the model commands (all commands before this average time amount is not executed) but the nodes never execute the commands from the config client model (even after 5mins).

However I got the health alive beacon as soon as I'm reconnect to the network.

Edit : I have tried to change the beacon interval from the provisioner but no notable change. Its need to be change from the provisioner or from the node ?

Regards.

[neicureuil]

Otherwise you said before that its can be a problem with the IV index.

If I try to export the index and reload it at the start can it solve the issue ? If yes, how can I get this index from code ?

Regards

[Hung Bui]

Hi Neicureuil, 

I would suggest to have a look at this similar case here: https://devzone.nordicsemi.com/f/nordic-q-a/77056/i-want-to-recover-control-provisoned-device-when-i-reopen-the-pyaci-script-and-reset-the-52840-dk

Note that what you are trying to do is not something we have tested and also not defined in the spec on how it should work neither (multiple provisioners sync up).
So this would require you to study the code thoroughly to implement what you want to do and should be able to debug it. We will try to help you along the way but we are having limited resource at this moment due to Summer holiday in Norway. 

Regarding your question, as I mentioned earlier, you won't be able to talk to the configuration server from your client without the dev key. It's like the application key specifically for the configuration server on the node. 
Without the dev key (s) you won't be able to configure the node (s). 

 The time it take of 5 minutes to be able to talk to the network is a bit strange. I would need to talk to the team on why it take this much of time. 

[neicureuil]

Hi,

Thanks for your answer, the export and import of the device dev key works ! The config model now works fine. Thanks.

Is there any way to change the devkey generation for the nodes (my nodes use the "light_switch_client" example from the mesh sdk), (I have do it for my provisioner but I don't find where its done for the node) ?

Will it be possible to be kept informed about the 5 minute delay ?

Regards.

[Hung Bui]

Hi Neicureuil, 

As far as I know the device key is generated in prov_utils_derive_keys() in prov_utils.c if you are using the provisioner or the serial example. If you use the phone you would need to look into the app code. 

But note that, there is a rule about how the device key should be produced in the Bluetooth Mesh spec. Changing that risk the chance that your device won't be able to qualify and it would increase  security vulnerability.