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 just tried to debug the iv index with "net_state_beacon_iv_index_get()" on both side. I'm surprised to see that its return 0 on the both side, even after model commands sending.

Regards

[Hung Bui]

Hi Neicureruil, 

When did you call this function ? It's normal for a network to start with IV index = 0. 

[neicureuil]

Hi,

I call it each time I received an alive event, and each time I received a model command acknowledgment. 

I have tried to set a custom IV index just after the mesh init and start function with net_state_iv_index_set. But same thing append, each time I debug it (same places that before) its return the same index (the index that I previously set) and its never increase.

Regards

[Hung Bui]

Please explain exactly what you did. I'm not sure I understand what you mean by "same places that before)
Calling net_state_iv_index_set() won't store the iv_index into flash. 

[neicureuil]

Hi,

This is how and where I try to debug the iv index :

The health model alive event callback :

// Node health model callback (send serial alive event).
static void app_health_event_cb(const health_client_t * p_client, const health_client_evt_t * p_event)
{
  switch (p_event->type)
  {
    case HEALTH_CLIENT_EVT_TYPE_CURRENT_STATUS_RECEIVED:
    {
      NRF_LOG_INFO("Node 0x%04x alive with %u active fault(s), RSSI: %d", p_event->p_meta_data->src.value, p_event->data.fault_status.fault_array_length, ((p_event->p_meta_data->p_core_metadata->source == NRF_MESH_RX_SOURCE_SCANNER) ? p_event->p_meta_data->p_core_metadata->params.scanner.rssi : 0));
      NRF_LOG_INFO("IV : %d", net_state_beacon_iv_index_get());
      
      break;
    }
    default:
      break;
  }
}

The custom model command callback :

static void my_model_client_status_cb(const hx_model_client_t *p_self, my_model_client_status_t status, const uint8_t *p_data, uint16_t length, uint16_t src)
{
    uint8_t* message = (uint8_t*)malloc(RX_DATA_COUNT_MAX);
    memcpy(message,p_data,length);

    NRF_LOG_INFO("Response from MY SERVER MODEL: %s, length is %d, status is %d, Source Address: %x", message, length, status, src);
    NRF_LOG_INFO("IV Index from model : %d", net_state_beacon_iv_index_get());
    
    process_event(src, p_data, length);
    
    memset(message,0x00,RX_DATA_COUNT_MAX);
    free(message);     
}

When I said "same places that before", its just means that I use the same log line at the same code place.

Regards

[Hung Bui]

Hi again, 

Please clarify that in your case it's been always IV-Index = 0 even though your new provisioner couldn't enter the network ? 

I would suggest checking the data stored in flash of the old provisioner and the new provisioner to see if you can spot any difference. 

[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