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, 

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. 

[neicureuil]

Hi,

Thanks for the answer, temporally I have override the devkey generation function by a custom one based on the device mac address and uuid, so I can recreate it in the mesh network reload process.

Otherwise, can the provisioner update the devkey of the node after the provisioning process or once the key is set, it cannot be changed ?

My issue of the IV index delay can it come from my mesh sdk version (4.2.0) ?

Regards.

[Hung Bui]

Hi Neicureuil, 

I don't think it's possible to change the devkey. You would need to reprovision the node to get a new devkey. 
I'm still waiting for the mesh team about the question about the 5 minutes delay for IV index update. 

[neicureuil]

Hi,

Thanks for all.

I want to check if its really  a IV Index issue, for that I want to debug it on the both side (provisioner and node) and see what's append.

Can you say to me how can debug the IV Index (which variable I need to log) ?

Regards

[Hung Bui]

Hi Neicureuil, 

The current IV Index is stored in m_net_state.iv_index in net_state.c .  If the device is provisioned the IV index is restored when the mesh config is loaded from flash (mesh_config_load). When net_state_enable() (restored_result_apply()) is called the IV index from flash will be applied to  m_net_state.iv_index. 

The Secure Network Beacon is handled in net_beacon_packet_in inside beacon_packet_in() inside net_beacon.c . You can turn on logging at LOG_LEVEL_DBG1 level for LOG_SRC_NETWORK to get the info about the process on the log. 

The actual update of the IV index is handled in incoming_data_received() in net_state.c .

Note that if the difference between the current IV index in the node and the actual IV index in the network is above NETWORK_IV_RECOVERY_LIMIT (42) the node would need to be re-provisioned.