Read the current mesh IV index

[AndyM]

Hello
I need to read the current mesh IV index of a provisioned node.
Found 2 structures with the iv_index field : struct bt_mesh_cdb bt_mesh_cdb and struct bt_mesh_net bt_mesh
Only bt_mesh_cdb is publicly available - the struct bt_mesh_net declaration is in the private header net.h which is not accessible at the application level
Is my assumption correct, that the updated IV index is saved in the cdb and bt_mesh_cdb object always has the updated value?

If so - I could just read the iv_index field of bt_mesh_cdb.
Or is there another "official" way?
I only need to read the current IV index so I can pass it to the mesh shell provision command

Another question (though it was discussed in a previous ticket,just want to clarify and confirm)
If a node is provisioned with mesh shell provision command with IV index 0 on the network where the current IV index is non zero - what happens? Does the newly provisioned node eventually catch up and can communicate?
Thanks

Andy

[tesc]

Hi,

If so - I could just read the iv_index field of bt_mesh_cdb.
Or is there another "official" way?

I am not quite sure on this one, so I have asked internally and will provide an answer within a couple of days. From past experience I know that fetching security info out from the CDB is difficult (if not impossible) due to security reasons. Typically one is left with having to use stack APIs, and the stack itself handles network keys, etc. under the hood and outside of reach for the application. For instance, if your node is a provisioner you just use the provisioner APIs and it will use the correct values from the CDB without you having to handle them at the application level.

If a node is provisioned with mesh shell provision command with IV index 0 on the network where the current IV index is non zero - what happens? Does the newly provisioned node eventually catch up and can communicate?

The node will not catch up. There is a procedure for IV Index recovery, but only if the node is lagging behind by 42 or less IV Indexes. If the newly provisioned node gets an IV Index of 0, and the network has anything outside of the range of 0 through 42, then the new node will not be able to communicate with the rest of the network. It simply have to be provisioned with an IV Index close enough to the network, that it will recover. Ideally it is provisioned with the correct IV Index for the network, so that it can start communicating right away and without having to do recovery.

Regards,
Terje

[AndyM]

Thank you for clarifying the node behavior

Since I provision my devices with mesh shell commands  this behavior makes it crucial to pass the correct IV index to the node.  Look forward for the answer from your team about the correct way to obtain the current IV index
You mentioned that "there is a procedure for IV index recovery" 
Is there a public API to start IV index recovery ?
If so my device could always the recovery after it is provisioned, to ensure the IV index is in sync with the rest of the network

Will that work?

Thanks

[tesc]

Hi,

There is no official way to get the IV Index, unfortunately, but the suggestion I got from the team was to try to use the extern struct bt_mesh_net bt_mesh from zephyr/subsys/bluetooth/mesh/net.h as it is a global state.

IV Index Recovery is handled automatically by the stack. If the node receives a secure network beacon with an IV Index in the range 2 to 42 higher than the currently registered IV Index, the node will perform the IV Index Recovery procedure. This cannot be overridden by the application, and the behavior cannot be changed without voiding qualification.

Regards,
Terje

[AndyM]

Thank you

Appreciate your help