MESH key refresh support in the Serialization interface (ACI)

[dbuijsma]

I'm using the MESH SDK 4.2.0 on a nrf52832 in combination with the Serialization interface (ACI) example

We'd like to implement the key-Refresh cycle and are planning on the following sequence:

1. Phase 0 => 1:   dsm_subnet_update()            (SERIAL_OPCODE_CMD_MESH_SUBNET_UPDATE).[optional]      dsm_appkey_update()            (SERIAL_OPCODE_CMD_MESH_APPKEY_UPDATE)
2. Phase 1 => 2:   dsm_subnet_update_swap_keys()  (???)
3. Phase 2(3)=> 0: dsm_subnet_update_commit()     (???)

There's an APIs for the first step, but I do not see a way to execute step 2 and 3 without adding an API: are these missing? 

Thanks,

Dirk

[Mttrinh]

Hi,

There aren't any APIs for that. Those extra commands from 2) and 3) are not needed. You are able to acheive the same effect by letting the PyACI send a config client message KEy Refresh Phase Set to the config server on the connected serial device.

[dbuijsma]

Interesting, I had not thought of that. So they config client on my device would send a CONFIG_OPCODE_KEY_REFRESH_PHASE_SET message to its own config-server using the local bearer CORE_TX_BEARER_TYPE_LOCAL (eg, it does not use its own radio?

I'll try this out.

There are serialization calls for similar functions like SERIAL_OPCODE_CMD_MESH_APPKEY_ADD. Couldn't those  be treated the same way? (in that case CONFIG_OPCODE_APPKEY_ADD). Assuming I have that correct, why the distinction in the API?

And for that matter: the SERIAL_OPCODE_CMD_MESH_SUBNET_UPDATE  and also be executed by using the config client's CONFIG_OPCODE_NETKEY_UPDATE message. 

Could you clarify?

[Mttrinh]

dbuijsma said:

So they config client on my device would send a CONFIG_OPCODE_KEY_REFRESH_PHASE_SET message to its own config-server using the local bearer CORE_TX_BEARER_TYPE_LOCAL (eg, it does not use its own radio?

Packets addressed to themselves is handled without using the radio. Before using that command, PyACI config client should be configured to communicate with the config server on the connected serial device by using "publish_set()"

Also, to do this properly it requires modifications of the "load()" function in "provisionin.py" to add the devicekey for the serial device.

dbuijsma said:

There are serialization calls for similar functions like SERIAL_OPCODE_CMD_MESH_APPKEY_ADD. Couldn't those  be treated the same way? (in that case CONFIG_OPCODE_APPKEY_ADD). Assuming I have that correct, why the distinction in the API?

Are you wondering if SERIAL_OPCODE_CMD_MESH_APPKEY_ADD and CONFIG_OPCODE_APPKEY_ADD do the same thing? and if so why the distinction in API?

[dbuijsma]

Mttrinh said:

Are you wondering if SERIAL_OPCODE_CMD_MESH_APPKEY_ADD and CONFIG_OPCODE_APPKEY_ADD do the same thing? and if so why the distinction in API?

Yes exactly: why have a SERIAL API for APPKEY_ADD but not for other functionality? It would be good to understand the API architecture better. 

[Mttrinh]

Hi,

SERIAL_OPCODE_CMD_MESH_APPKEY_ADD and CONFIG_OPCODE_APPKEY_ADD do the same but their destination/targets are different.

The difference between config messages and serial API is that you can use a config client to send config messages. It will work on all nodes in the network, if the serial node have a config client. While serial APIs works directly, not dependent on a node having a config client.