I want to recover control provisoned device, when I reopen the PyACI script and reset the 52840 DK

[oplinux]

Dear friends,

When I reset 52840 DK and reopen the PyACI script , then, reloading the DB(database/example_database.json), I found the provsioned device can't be controled again.

I refrence this case ，however,  we can't get any data from the provsioned device, attach my test code:

db = MeshDB("database/example_database.json")
p = Provisioner(device, db)
device.send(cmd.DevkeyAdd(db.nodes[0].unicast_address, 0, db.nodes[0].device_key))
device.send(cmd.AddrPublicationAdd(db.nodes[0].unicast_address))
cc = ConfigurationClient(db)
device.model_add(cc)
cc.publish_set(8, 0)
cc.composition_data_get()

and the test log:

E:\bluemesh\fortest\nrf5_SDK_for_Mesh_v2.2.0_src\scripts\interactive_pyaci> C:\Users\admin\AppData\Local\Programs\Python\Python38\python.exe interactive_pyaci.py -d COM4

    To control your device, use d[x], where x is the device index.
    Devices are indexed based on the order of the COM ports specified by the -d option.
    The first device, d[0], can also be accessed using device.

    Type d[x]. and hit tab to see the available methods.

Python 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 7.23.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]:

In [2]: db = MeshDB("database/example_database.json")
   ...: p = Provisioner(device, db)

In [3]: 2021-07-02 17:32:31,468 - INFO - COM4: Success
2021-07-02 17:32:31,469 - INFO - COM4: Success
2021-07-02 17:32:31,473 - INFO - COM4: SubnetAdd: {'subnet_handle': 0}
2021-07-02 17:32:31,481 - INFO - COM4: AppkeyAdd: {'appkey_handle': 0}
2021-07-02 17:32:31,482 - INFO - COM4: AppkeyAdd: {'appkey_handle': 1}
In [3]:

In [3]: db.nodes[0].unicast_address
Out[3]: 0010

In [4]: device.send(cmd.DevkeyAdd(db.nodes[0].unicast_address, 0, db.nodes[0].device_key))
   ...: device.send(cmd.AddrPublicationAdd(db.nodes[0].unicast_address))

2021-07-02 17:32:46,728 - INFO - COM4: DevkeyAdd: {'devkey_handle': 8}
2021-07-02 17:32:46,729 - INFO - COM4: AddrPublicationAdd: {'address_handle': 0}In [5]:
In [5]:
In [5]: cc = ConfigurationClient(db)
   ...: device.model_add(cc)
   ...: cc.publish_set(8, 0)
   ...: cc.composition_data_get()

2021-07-02 17:32:56,990 - INFO - COM4: Success
In [6]:

In [6]:

In [6]:

In [6]: cc.composition_data_get()

In [7]: 2021-07-02 17:33:17,492 - INFO - COM4: Success
In [7]:

In [7]:

Could you give me some advice for realize this functionality?

Thank you in advance.

[Hung Bui]

Hi Oplinux, 

Please have a look at this discussion: https://devzone.nordicsemi.com/f/nordic-q-a/53613/some-questions-about-provisioning-with-pyaci

Please ignore my initial information that "Devkey can't be readded" it's possible. 

So, from what you can read in the case you pointed to and the case above, you can find that you need to restore the database on the nRF52 to make it work again after you reset. 
I have some suggestions in the case with Wataru that you can refer to. We unfortunately still don't have any example to do the task yet. 

[oplinux]

Thank you very much Hung,

With the suggest "you need to restore the database on the nRF52 to make it work again after you reset", 

a) I want to konw the format and content about the the database on the nRF52.

b) Which parameters should I store in this database?

c) How to create this database on 52840 Soc.

d) Is there some APIs can achive this database?

Best regards,

Oplinux

[Hung Bui]

Hi Oplinux, 

By default if the new node doesn't have the correct IV Index (or it was inactive for too long), it should listen to the Secure Network Beacon. Please have al look at section 3.9.3.1 in the Mesh Profile Spec, especially Section 3.10.6 IV Index Recovery procedure.

I believe all of these is performed transparently to the application as it should be handled by our mesh stack. 

I would suggest to test with IV index = 0 first, just to make sure your new provisioner can talk to the mesh network. 

[oplinux]

Thank you Hung,

I have read Section 3.10.6. There are two questions:

a)  Which serial command can listen to the Secure Network Beacon?  in the tutorial, I only found Provisioning commands has a "Scan Start" option which is used to scan unprovisioned beacons.

b) Similarly, Which command can I called to start the procedure of update IV Index? the existing mesh network's IV index  is 287454020, the new provisioner's IV index is 0.

My 52840 DK flashed serial example(nrf5_SDK_for_Mesh_v5.0.0_src\examples\serial)

Best regards,

Oplinux

[Hung Bui]

Hi Oplinux, 
Please note that we are talking about Secure Network Beacon, not the unprovisioned beacon. This beacon is sent automatically by other mesh nodes in the network. The node should be able to catch this beacon after a few minutes. But only if it has joined the network properly. 

It's also possible to update the IV index manually from the node. We provide an API on the serial interface that you can call from the Python side: SERIAL_OPCODE_CMD_MESH_NET_STATE_SET (0xAE) 

Following are the info you need to feed in the call: 

typedef struct __attribute((packed))
{
    uint32_t  iv_index; /**< The IV index to set.*/
    uint8_t   iv_update_in_progress; /**< Value indicating the phase of the IV update process. */
    uint16_t  iv_update_timeout_counter; /**< Timeout counter for IV update process. */
    uint32_t  next_seqnum_block; /**< The first sequence number block which is not yet allocated. */
} serial_cmd_mesh_net_state_set_t;

You would receive SERIAL_OPCODE_EVT_MESH_IV_UPDATE_NOTIFICATION after the IV index is updated. 

But I would suggest to verify that your new provisioner can actually talk to the network without doing IV index (reinitialize the network so that IV index is 0). Just to verify that everything else works, then you can start updating the IV index. 

[oplinux]

Thank you Hung,

I have been tryed this command "SERIAL_OPCODE_CMD_MESH_NET_STATE_SET", it works well, however, you konw, this process should manually operate. I want to use IV index recovery procedure to automaticly finish it. so, I faced two questions:

a) In the provisoner side, how to scan secure network beacon to get IV index value, which serial API can be used to realize this purpose? I have tested new provisioner can't  talk to the network without doing IV index.

b) For start IV index recovery procedure, which serial API can be used to?

Best regards,

Oplinux

[Hung Bui]

Hi Oplinux, 

As I mentioned earlier, the Secure Network beacon scanning and the IV index recovery procedure should be done automatically by the mesh stack. You don't need to call a function to scan or do anything to recover the IV Index. It's the same as when a node is inactive for too long it should recover automatically without the need of a call from the application. 

Have you tried to leave the new provisioner for a few minutes ? But you need to make sure that it has the correct network key. 

[oplinux]

Thank you Hung,

I'll try it again. The new provisioner has been assigned the correct network key. However, when the new provisioner sends messages to other nodes, those nodes can't parse it, because the IV index value of the mesh network is 287454020, the IV index value of the new provisoner is 0.

For the mention "the Secure Network beacon scanning and the IV index recovery procedure should be done automatically by the mesh stack.",

Could you tell me this process will take about how long it will take to finish?

The only thing I need to do is wait?

Best regards,

Oplinux

[tesc]

Hi,

I am afraid the IV Index Recovery procedure can only be used if the difference in IV Index is 42 or less. According to Mesh Profile specification section 3.10.5 IV Update procedure:

"If a node in Normal Operation receives a Secure Network beacon with an IV index less than the last known IV Index or greater than the last known IV Index + 42, the Secure Network beacon shall be ignored."

In other words, if the indexes are 0 and 287454020, then according to specification the node is instructed to ignore the beacon and not do IV Index Recovery.

If the difference is 42 or less, then on average the procedure should start in 5 seconds (as the average time between Secure Network beacons is 10 seconds.)

In other words: You need to find and set an appropriate IV Index manually, e.g. through Bluetooth Mesh Net State Set and Bluetooth Mesh Net State Get. I suggest looking at the implementation for those, if needing to retrieve or set the same information through other means.

Regards,
Terje

[oplinux]

Hi tesc,

Thanks for your reply.

If we set IV index manually, the provisioner should scan Secure Network beacons and then get the newest IV index value, so, which serial API can I use to scan it?

Best regards,

Oplinux

[Hung Bui]

Hi Oplinux, 
The scanning of the Secure Network Beacon is automatically and transparently (a mesh node always scans). You don't need to call a function to scan. 

As Terje mentioned, the issue here is that the IV Index gap between local IV Index and network IV Index can't be more than 42. If it's more than 42 the node need to be reprovisioned. In this case it's a provisioner so we can think of updating it manually. 

The question is how you can catch the current network IV Index. What you need to do is to have a look at the incoming_data_received() in net_state.c. This is where the IV Index difference is checked. You can see the check for : 

            if (iv_index <= (m_net_state.iv_index + NETWORK_IV_RECOVERY_LIMIT) &&
                !m_net_state.iv_update.locked)

where NETWORK_IV_RECOVERY_LIMIT = 42. 

So you can either remove this check for difference <42 or you can just read the network iv_index out and send it to PC. After that from the PC you can send the IV Index back to the node using SERIAL_OPCODE_CMD_MESH_NET_STATE_SET . 

Note that if you remove the check for the difference <42, you may break the qualification for Bluetooth Mesh as an end product. But for testing/developing purpose it should be fine. 

[oplinux]

Hung and Terje, many thanks for your detailed replies.

I get it now, I'll try this way which you mention above.

Thanks again.