MESH key refresh support in the Serialization interface (ACI)

RE: MESH key refresh support in the Serialization interface (ACI)

dbuijsma — Tue, 10 Nov 2020 17:11:41 GMT

Ok, gotcha. I wanted to make sure I'm not missing something. Thanks for your patience!

RE: MESH key refresh support in the Serialization interface (ACI)

Mttrinh — Tue, 10 Nov 2020 14:02:08 GMT

Hi,

We provided serial APIs only for those function which are essential for the Gateway type devices. For functions where a serial API don't exist, you can add this on your own, or use the config client(on the PyACI) and server models(on the serial device) to configure specific functionality of the gateway node itself.

RE: MESH key refresh support in the Serialization interface (ACI)

dbuijsma — Thu, 05 Nov 2020 16:36:18 GMT

Let me clarify, because we're now talking about different things. SERIAL_OPCODE_... target the device itself, and as you mention above, the config client messages (CONFIG_OPCODE_...) target any node which has been successfully provisioned, including the device itself.

You mention in your first reply that there's no SERIAL API for starting a key refresh phase because you can achieve the same by using the config client's CONFIG_OPCODE_KEY_REFRESH_PHASE_SET. That makes sense to me.

However, by that logic, there's no reason for the existence of SERIAL_OPCODE_CMD_MESH_APPKEY_ADD or SERIAL_OPCODE_CMD_MESH_SUBNET_UPDATE either: you can simply use the config client after the serial-example provisions itself.

My question is: why do those serial APIs exist? The way the SERIAL API is currently implemented seems inconsistent:

- SERIAL_OPCODE_CMD_MESH_APPKEY_UPDATE exists, even though we could use CONFIG_OPCODE_APPKEY_UPDATE to update our own appkey. The same is true for APPKEY_ADD: there's does appear to be a need for a separate SERIAL API

- For setting the Key Refresh Phase, there's no SERIAL API and we have to use the config client's CONFIG_OPCODE_KEY_REFRESH_PHASE_SET. Again, this makes sense to me after you pointed that out in your first reply.

Thanks!

Dirk

RE: MESH key refresh support in the Serialization interface (ACI)

Mttrinh — Thu, 05 Nov 2020 13:31:43 GMT

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.

RE: MESH key refresh support in the Serialization interface (ACI)

dbuijsma — Tue, 03 Nov 2020 16:14:15 GMT

[quote userid="15475" url="~/f/nordic-q-a/67498/mesh-key-refresh-support-in-the-serialization-interface-aci/278129#278129"]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?[/quote]

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.

RE: MESH key refresh support in the Serialization interface (ACI)

Mttrinh — Mon, 02 Nov 2020 15:09:37 GMT

[quote user="dbuijsma"]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?[/quote]

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.

[quote user="dbuijsma"]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?[/quote]

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?

RE: MESH key refresh support in the Serialization interface (ACI)

dbuijsma — Tue, 27 Oct 2020 17:21:45 GMT

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?

RE: MESH key refresh support in the Serialization interface (ACI)

Mttrinh — Tue, 27 Oct 2020 12:51:20 GMT

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.