This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Mesh proxy re connection and sequence number

Hi

I re open an old ticket to know about changes in the Android Mesh Library

https://devzone.nordicsemi.com/f/nordic-q-a/45553/is-sequence-number-and-transaction-id-equal

I see that, now, the Mesh SDK for nrf52 keep a good track of sequence number and IV index. But we are still facing issues when a phone re connect to a proxy node.

To get the sequence number, we send a message to set a new proxy filter type (here blacklist 0x0000) and receive a new sequence number.

But sometime the board is not accepting the filter messages.

Also, the board is not accepting any message after the app came to foreground. when the app is in background, it is connected to the board all the time. so here we need to restarting the board before being able to send any new message.

Is there any way to get the board's sequence number without sending filter messages?

thank you very much.

Parents
  • Hi all

    Sorry for this long period of silence. I had a lot of things to care of.

    First, I would like to thank you all, for your help in this period of confinement.

    Yesterday, we made a good step in our comprehension of our problem: We still have an issue for the reconnection after stoping the app, and, in fact, this is our source of the problem:

    Restarting the app: As you said:

    Roshan Rajaratnam said:

    the app stores each sequence number related to a specific node address in an internal database.

    But, for us, the network configuration is stored online. We store it online each time the network changes, and we download it when the app starts, wiping the local database.

    We are working on a way to avoid this data loss, but we have a few questions that need answering, first:

    What is the reason why the sequence number isn't part of the data we get after exporting the network configuration? (Security? Volume?)

    Depending on this, we will decide 'where/if' we will store it, in addition to the local database.

    In case destruction/deletion of this local database (phone get lost or broken), how can we 'restore' it? or getting, a least, one correct connection to the nodes?

    To understand this problem, we invite you to create a mesh network with NrfMesh. Export it and wipe the app data, then, import the network configuration you export earlier.

    The NrfMeshh app will invite you to create a new provisioner, but is there a way to 'restore' the one we lost?

    Thank you

  • after some bad manipulation of the website, I accidentatly delete a part of the thead and your last message, that was very helpfull. Here is the content of it:

    According to the mesh configuration database specification, sequence numbers are not exported for security reasons hence the sequence number is not exported. If someone get's hold of the json spec they can start sending messages reusing an existing provisioner and their sequence number which will make the device reject the original provisioner. Exporting the sequence number would be a spec breaker for us.

    They can store the sequence numbers safely and separately (in their own cloud) themselves for each provisioner and each node address in the network. Therefore we have left the sequence number public if a user wants to store/set it manually themselves using the api as shown here.

    One solution would be to have their own database with the relevant network UUID, provisioner's sequence number for each node in the network. If not They can even append this information to the json file themselves and parse their information themselves and give the rest of the original to the mesh library which will parse the original json data.

Reply
  • after some bad manipulation of the website, I accidentatly delete a part of the thead and your last message, that was very helpfull. Here is the content of it:

    According to the mesh configuration database specification, sequence numbers are not exported for security reasons hence the sequence number is not exported. If someone get's hold of the json spec they can start sending messages reusing an existing provisioner and their sequence number which will make the device reject the original provisioner. Exporting the sequence number would be a spec breaker for us.

    They can store the sequence numbers safely and separately (in their own cloud) themselves for each provisioner and each node address in the network. Therefore we have left the sequence number public if a user wants to store/set it manually themselves using the api as shown here.

    One solution would be to have their own database with the relevant network UUID, provisioner's sequence number for each node in the network. If not They can even append this information to the json file themselves and parse their information themselves and give the rest of the original to the mesh library which will parse the original json data.

Children
  • Hi, 

    I want to go back on this sentanse : "The NrfMeshh app will invite you to create a new provisioner, but is there a way to 'restore' the one we lost?"

    If my smartphone controls a mesh network, it has a valid SeqN that I store in local. If I lose my phone and want to install an app (that control this network) on a new smartphone, is there a better procedure than recreating a new provisionner?
    Is there any other local solution to get back a valid SeqN?

  • Hi Olivier, 

    From Roshan:


    As of now, the spec does not state anything for a scenario like you have specified, but still there is a way around it. You can still use the backed up json to retrieve the last provisioner and change the provisioner address to something new and this should let you continue with a new sequence number if that address is not in use. 

     

    Sequence number is important in mesh it's used for encryption, identifying a unique messages from each device and also to protect devices from replay attacks. Our sample app will clear the local app data will erase everything just like any other app out there and it's only a sample app. You can improve your end user app to handle these case better. Like I mentioned before this is why we left the API open and provide our users with the flexibility just for purposes like this.

Related