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]

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