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

MESH key refresh support in the Serialization interface (ACI)

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

Parents
  • 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.

  • 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?

Reply
  • 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?

Children
No Data
Related