nRF Mesh android app mesh network import issues

[Steve Butler]

I'm unable to import/export mesh networks and then subsequently send mesh messages. I believe this problem has been mentioned before [1][2][3], but the solutions offered don't seem to work.

It seems that when a network is imported, the sequence no. needs to be incremented above what it was previously, or mesh messages are discarded.

A way around this (mentioned in the mesh api docstrings and github issues) is to change the unicast address of the current provisioner.

solution tried:

The application has a notion of multiple 'sites' that can be provisioned, so each site has it's own mesh network. When I navigate to a site in the app, the following occurs:

1. disconnect from peripheral if connected

2. fetch remote network json

3. import mesh network from json

4. if the network contains nodes other than the provisioner:

  a. get next available unicast address for network

  b. assign new address to network (not sure if necessary?)

  c. assign new address to selected provisioner

  d. update provisioner

  e. re-set as selected provisioner

To my knowledge, I'm doing what is stated in the docstrings and what has been mentioned elsewhere. However if I manually set the sequence number to the previous value (pre-network import), or send enough messages to exceed the previous sequence number, then mesh messages send successfully again.

Why does changing the unicast address of the provisioner not work? Am I missing something?

Whilst I'm implementing my own application, the steps to replicate this behaviour in the nRF Mesh app (version 3.3.7) are:

1. install app

2. export network (network_1.json)

3. reset network

4. provision a device into the network, bind app key, test mesh messages work

5. export network (network_2.json)

6. import network_1.json

7. import network_2.json

8. connect to device and try send mesh message (will timeout)

9. update provisioner's unicast address

10. re-try sending mesh message (will still timeout)

[1]: devzone.nordicsemi.com/.../239349

[2]: github.com/.../248

[3]: github.com/.../336

[Amanda Hsieh]

Hi, 

Each Element, identified by a Unicast Address, in a mesh network must always use a higher Sequence Number then was used previously from the same address (those are stored in the Reply Protection List on Relay Nodes and nodes that processed each message from that Element).

This "last Sequence Number" isn't stored in JSON, and it is not exported, as it changes too quickly. It is, however, stored locally on the phone, so after the app is restarted, the last Seq Num is loaded. When you export/import a mesh network on a phone that doesn't have this Sequence Number stored for this given Unicast Address, such a node would start sending messages with Seq Num = 0. They are discarded on all other nodes until they are greater than what they knew before. This is expected behavior. 

A solution is to use a unique Provisioner on each phone. Before exporting user shall create a new Provisioner in nRF Mesh / Settings / Provisioners, assign it a unique Unicast Address and range of addresses for unicast addresses, groups, and scenes, and only then export the network. On the other phone, which imports the network, you will be asked to select which Provisioner instance shall be assigned to that phone. You need to select the new Provisioner from which address no message has yet been sent. The 2nd phone is free to transmit messages with Seq Num = 0, other nodes will add this source address to their RPL.

It is also possible to export mesh network config with a subset of nodes, and a subset of Provisioners. I.e. user can select only the 2nd Provisioner to be exported. The 2nd phone, upon import, will simply assign that Provisioner instance to itself, as there's no other choice. Such "partial" export prevents this new phone to send a Config message to the 1st phone, i.e., a Config Node Reset (which requires the Device Key of the 1st Provisioner's Node).

Why does changing the unicast address of the provisioner not work? Am I missing something?

This should be sufficient, given they changed to a new address, which was never* used.

*-never expires when the IV Index changes high enough that it can be reused.

Regards,
Amanda H.

[Steve Butler]

A solution is to use a unique Provisioner on each phone.

I'm not even looking at multiple phones at the moment, though that is the end goal. I'm currently just wanting to switch between different mesh networks whilst on the same phone.

This should be sufficient, given they changed to a new address, which was never* used.

The steps I take (all on the same phone) are below:

1. create new mesh network mn1 (provisioner has unicast addr. 0x0001)

2. provision device in mn1 (device elements have unicast addr's 0x0002 -> 0x0005)

(mesh messages can be successfully sent at this point)

3. export mn1 to remote db

4. create new mesh network mn2 (provisioner has unicast addr. 0x0001)

5. export mn2 to remote db

6. re-import mn1 from remote json (provisioner unicast set to nex available addr, 0x0006)

(again, mesh messages can be successfully sent as the unicast address is changed and never used before)

7. re-import mn2 (provisioner addr stays as 0x0001 as there's no provisioned nodes)

8. re-import mn1 (provisioner unicast set to next available addr, 0x0006)

(unable to send mesh messages, until I change unicast address to 0x0007. I'm assuming this is because 0x0006 has been used previously?)

Now I could just ensure that every time I switch networks I set the provisioner to a previously unused unicast address. But doing this would limit the number of times I could switch between networks?

[Amanda Hsieh]

Hi, 

We need to test this. Ideally, step 8 should not set the address to 0006; it should be 0001 as it was before.

-Amanda H.