Some questions about provisioning with PyACI

RE: Some questions about provisioning with PyACI

wataru_m — Wed, 30 Oct 2019 09:24:49 GMT

Hi Hung,

Thank you for your suggestions.
I will try the proposed method, and I will come back if I have any questions!
In that case, please help to solve it again.

Best regards,
Wataru

RE: Some questions about provisioning with PyACI

Hung Bui — Wed, 30 Oct 2019 08:45:04 GMT

Hi Wataru,

Yes, in my opinion your understanding is correct. Unfortunately, I haven't tried myself here to do what you want to achieve. I would suggest you to try and if you have any problem, please let me know we can try to solve.

RE: Some questions about provisioning with PyACI

wataru_m — Wed, 30 Oct 2019 02:11:30 GMT

Hi Hung,

I'm sorry, I'm getting a little confused.

[quote userid="2121" url="~/f/nordic-q-a/53613/some-questions-about-provisioning-with-pyaci/216676"]It's not designed to be a production tool that you can use out of the box.[/quote]

You had said before as above.

However, in fact, I think that it might could be said that it is designed as a ready-to-use tool, except that there is no Python script that automatically adds each handle or key to nrf52 from the json file. Isn’t it?

I interpreted that it would be fine if I was not burdened to operate PyACI by manually adding the information to nrf52 or extracting some key etc. which I need from previous LOG information (of course manually).

If my interpretation is correct, the proposed # 2 approach can certainly be avoided.
In fact, I couldn't imagine that it would require such a big fix...

For a while, I don't think I need to worry about the upper limit of the database information that can be stored in nrf52.
(For now, there are no plans to build a large network of hundreds or thousands yet.)

Am I overlooking something?

Best regards,
Wataru

RE: Some questions about provisioning with PyACI

Hung Bui — Tue, 29 Oct 2019 09:50:54 GMT

Hi Wataru,

For approach #1, keeping the dsm, I don't think you would need to modify the code (in nRF52 and pyACI). I haven't tried myself but my understanding is that you need to add the address, the device key, to the nRF52 to restore the database. What is missing is the code in python to automate the process.

For approach #2, removing the dsm, the part that affect is not provisioning part but the configuration part where we use the configuration client to configure the server on the provisionee. The modification would require large code modification of the access layer and the model layer. I would suggest to go for approach #1. If it works for you we can avoid spending too much work on approach #2.

RE: Some questions about provisioning with PyACI

wataru_m — Tue, 29 Oct 2019 07:42:55 GMT

Hi Hung,

I see, thank you.
It might be an extreme analogy, but let me know if I'm wrong.
Even, I am not thinking this is the best policy (In the sense that using DSM,).

Assuming I have a .json file with mesh network information.
If I want to reconfigure a node who participating in the network,
or if I want to add a new device to the network,
It may be no problem to prepare a new NRF52 which flashed mesh serial project each time and restore the database to NRF52.

I agree with your opinion.
I know I need to refactor, but I don't have any idea at the moment which source files are for.

Are the files listed in the "Serial" folder and the files listed in the "Provisioning" folder in the .emProject file subject to editing?

I also need to edit other Python files, right?
I think it will take time, but I would like to achieve this if possible.

Best regards,
Wataru

RE: Some questions about provisioning with PyACI

Hung Bui — Mon, 28 Oct 2019 12:45:27 GMT

Hi Wataru,

1. I don't see any problem if the keys being added and rejected.

2. We currently don't have an example or discussion on how to achieve that. Actually it's possible to restore the database in the NRF52, you would need to call AddrPublicationAdd, DevkeyAdd etc, to add the keys/address back to the database on the nRF52. The draw back is that there is a limitation of the size of the database on the NRF52.

The better solution in my opinion is to avoid using the dsm database on the NRF52. What the NRF52 does is to simple do the provisioning and send the information, handle, keys back to PC without storing any handle. But this would require refactoring the code of the serial example, the provisioner etc.

RE: Some questions about provisioning with PyACI

wataru_m — Mon, 28 Oct 2019 00:50:09 GMT

Hi, Hung

Thank you for your reply.

1. Is it safe to assume that doing this is not a problem just because you don't expect the key to be added again?
Without this process, I think that no other way to add devices to the network when using PyACI.

2, 3, 4. PyACI misunderstood that it was provided as an out-of-the-box production tool.
Sorry, I've gone and jumped to conclusions.

I want to move dsm database to a PC, in other words,
try an approach that can manage network information with a single database (On PC),
but what kind of place should be reconsidered specifically? Are there any hints?

Or, if such discussions and examples are already handled in some DevZone cases, etc.,
I would appreciate it if you could give me that information.

5. Thank you, I was relieved that my understanding was correct.
I will keep that (cannnot change or add keys) in mind.

Best regards,
Wataru

RE: Some questions about provisioning with PyACI

Hung Bui — Thu, 24 Oct 2019 15:15:46 GMT

Hi Wataru,

1. I think this is related to that the nRF52 serial firmware doesn't expect that the COM port will opened again and the keys to be added again.

2&3. Also related to #1, the PyACI is made as an demonstration of what you can do with the serial firmware. It's not designed to be a production tool that you can use out of the box. So there are 2 places that the database is stored. One is in the .json file and one inside the nRF52840. Unfortunately, we haven't got the option to restore the database on the nRF52840 after it's reset or if you want to copy the database to other board. This explains the behaviour you see with devkey_handle and address_handle in #3. Or when you reset the board, you won't be able to access those device/handles that you provisioned before.

Devkey can't be readded, different to publication address, we don't have a mechanism to check if the address is already added to the database.

4. This also related to what I described in 2&3, the database is stored in both the nRF52 device and on PC. The configuration on nRF52 is hardcoded and can't be changed dynamically.

The solution for all of this is in my opinion is to make a different version of serial firmware that move the location of dsm database from the nRF52 to PC. And the nRF52 would need to access PC to get the database for example the handle of the address, device key. This way it would work when resetting the board, multiple boards, etc. Unfortunately, we don't have the code example doing this yet.

5. Yes you are correct. You can modify the appkey and netkey on your own. It's added at the beginning when you open the COM port but can't be added twice or modify as in #1.