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

[neicureuil]

Hi,

I have made the IV index debug tests without reloading the network. I have just launch the provisioner, provision two devices, send model commands to them and just look a the logs to understand how IV index works usually. But the issue is that the IV index that I got is always 0.

I have made the same debugs tests on the nodes it self and I got the same issue.

Regards

[Hung Bui]

Hi Neicueruil, 

Please I have mentioned earlier that it's normal that IV Index = 0 at the beginning of the network. It only be updated to 1 after 96 hours. Which IV Index you were expecting in your test ? 

[neicureuil]

Hi,

Oh ok. I thought the index was incrementing with each command.

So, the fact that the config and custom model don't respond during the 5-10 minutes after the network reload while the health model receives the alive events doesn't look like an iv index problem because during my tests, the time elapsed between the creation of the network and the reload of the network was about 5-10 minutes.

Would it be possible to have the name and the file of the functions through which the received message passes between the moment when the NRF chip receives it and the moment when it is transmitted to the model ? I will try to debug all the path to see at which level the received message does not fulfill the condition to pass to the higher level.

Regards

[Hung Bui]

Hi, 

My favorite place for debugging is in the access.c file. Please look for the log where we print "TX:" and "RX:" 

It's on the access layer right before getting to the model. 

From that you can trace up to the transport layer. For example the function upper_transport_access_packet_in() in transport.c is where the packet receved in upper transport layer, before getting to access layer. 
Before the transport layer is the network layer, the packet is handled in network_packet_in() in network.c 

[neicureuil]

Hi,

I have put some logs in  upper_transport_access_packet_in and network_packet_in on the nodes side.

After the provisioning I have logs and all works nice but after a network reload, always health model events are received by the provisioner from the node, but I didn't get logs for commands sending by the provisioner on the node side, so I think it's either a problem in an even lower layer or it's the provisioner that doesn't send the message..

I will try soon to logs the provisioner side to be sure that the model message is correctly send on the network after the provisioner reload the network.

Regards

[Hung Bui]

Hi Neicureuil, 

I would suggest to test trying to add a new "normal" node to the network by hardcoded provisioning, instead of adding the new provisioner. 
This way it's easier to test if the model that is not health model works or not. 
As I mentioned, you may want to compare what you hardcoded to what stored in the flash if they are the same. You can use two identical node, one is provisioned by a provisioner and one is hardcoded provisioning data that you added. 

[neicureuil]

Hi,

I don't find anything inconsistent in sending the model messages.
Is there another index that would be related to the number of messages sent by models (like IV but will be increase at each model message, or a thing like that) ?

Regards

[Hung Bui]

I guess you are looking for sequence number, please look for sequence_number in the code. 

[neicureuil]

Hi,

After few tests, its seems to be a sequence number issue. I will still do more tests to be sure.

Now what I don't understand is why when I reload my network and turn the nodes off and on, they respond directly to the provisioner's message without having to wait 5 minutes.
Normally the sequence_number and iv_index should be stored in flash and reloaded when the node is started. They should therefore theoretically take the same amount of time (5 mins) to respond to  messages (the time to re-synchronize with the provisioner).

Why would turning the nodes off and on solve the problem?

Regards

[tesc]

Hi,

There are two mechanisms at play, which can explain behaviors related to sequence numbers:

1) For incoming packets, the sequence numbers received from "known devices" are stored in RAM only. That means if you reset a device then it will accept a series of packets starting from any sequence number. (But when additional packets comes in, it will only accept those with a higher sequence number than any other packet received after the reset.)

2) For outgoing packets:

If the stack were to store the sequence number to flash every time the node sent a message, then the flash would quickly wear out. Therefore the sequence number is held in RAM.

It also must be able to start at a higher number after the next reset, so some information must be stored to Flash.

The solution is that a sequence number is written to Flash, but that number is significantly higher than the "real" sequence number in RAM. It does not have to be updated in Flash until the number in RAM gets close to it, but whenever that happens it is increased by a lot. That way it seldom writes to Flash, but still ensures we always have a higher number in Flash than what we have in RAM. That way, after a reset, the stack can continue from the value read from Flash, which guarantees it starts on a higher number than has ever been used earlier.

This mechanism has the side effect that every time the device is reset, it will increase its sequence number by a lot. (By default the number in Flash increases by 8192 both on reset and whenever the number in RAM gets close to the current number.)

Regards,
Terje