After the Bluetooth mesh dfu is completed, the distribution network information of the node is cleared

[llly]

I have implemented DFU functionality in my Bluetooth mesh project and used device A as the distributor and device B as the node to be updated. I have already configured both devices and they can communicate with each other. Then I use the distributor to send new firmware to the node. After the node firmware is successfully updated, the original distribution network information of the node is cleared. At this point, the distributor and the node cannot communicate and need to manually reconfigure the distribution network. How can the original distribution network data be retained during DFU updates?

[Hung Bui]

Hi Illy, 
Please describe how you did the DFU update ? 
If you use the phone to send the image please check this similar ticket : BLE Mesh NCS: Provisioned data lost after DFU 

[llly]

Hi

There are two examples in NCS: Bluetooth mesh distributor and Bluetooth mesh target. I am using these two examples to test the performance of mesh DFU.

After downloading these two examples to two devices, the first step is to use a mobile phone to send the new firmware of the node to be updated (i.e. the device running the Bluetooth mesh target) to the distributor, and then control the distributor to send the new firmware received from the mobile phone to the node to be updated through a shell command. In other words, the node to be updated will not directly communicate with the mobile phone, but will forward the new firmware from the mobile phone to the node to be updated through the distributor. Therefore, the erase option on the mobile phone has no effect (the erase nvs partition option is turned off by default during updates, and can only be manually enabled to erase nvs partitions, but I have never enabled it)

[llly]

Hi

I found this log and it does show that after the update, it will become an unprovisioned node

I now understand why he encountered this situation. When I downloaded the mesh dfu target example to the device and used it to build the generated upgrade package for upgrading, the hash he read and calculated were consistent, and it would not become an unprovisioned device after the upgrade was completed.

But in my own project, the hash calculated based on the metadata of the upgrade package is different from the hash originally included in the upgrade package, resulting in the device becoming an unconfigured device after the unprovisioned is completed.

So why do the hashes calculated in my project differ? The metadata I filled in is correct, and I have tried using a distributor example to upgrade the nodes of my project. The computed hash is also different, which indicates that the problem lies in the nodes of my project

[llly]

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/bt/bt_mesh/dfu_over_bt_mesh.html#manual_metadata_generation

According to the instructions in this document, I manually entered parameters using shell commands and calculated the hash value, which is consistent with the hash value calculated by the device during updates. The problem now is that the hash value in the upgrade package automatically generated during construction is different from the hash value calculated by the device

In the first screenshot, the manually generated hash value is 0xbcce424f, The hash value in the upgrade package is 0xdb33f61b in the second screenshot

Both of these hash values can be found in the device log

[llly]

The reason for the two hash values being different has also been identified. It is because I used a vendor customized model in my project, but there is still an issue at this time. I have changed BT_MESH_ELEM(0, models, vendor_models) to BT_MESH_ELEM(0, models,  BT_MESH_MODEL_NONE)in my project to cancelled the vendor custom model. At this time, the hash value in the upgrade package is consistent with the calculated hash value

And the two hash values after adding the manufacturer's custom model are the same as those in my previous reply

[Hung Bui]

Hi Illy, 

Please clarify, after you managed to get the same metadata hash, do you still have the issue of the device unprovisioning itself ? 

[llly]

Hi

When the hash is the same, there will be no problem of becoming an unprovisioning device

The problem to be solved now is that after adding the manufacturer's custom model, the hash value in the automatically generated upgrade package is different from the calculated hash value

[Hung Bui]

Hi, 

llly said:

The problem to be solved now is that after adding the manufacturer's custom model, the hash value in the automatically generated upgrade package is different from the calculated hash value

Please let me clarify this, when you change the manufacturer custom model, the hash is different and you have to do re-provisioning, correct ? 
Then I don't see it as an issue. This is how it's defined in the Bluetooth specification. When the composition data is changed, the device has to be reprovisioning. 

I'm not so sure what can be a workaround here, as it's something needed for the provisioner to know what your device now have. Manually changing the hash value is not the way to go here as it a bad hack in my opinion and will cause a trouble. 

Could you explain the change you have in the composition data ? Do you plan to have that change very time you do DFU ? 

[llly]

Not adding new models after updating, but choosing whether to add vendor customized models before compilation

I am testing. If the vendor custom model is not added to the code, everything will be normal. If a vendor defined model is used in the code, the hash values in the upgrade package automatically generated by NCS will be different.

But in actual projects, I need to use vendor custom models, whether before or after updates, so I am not adding vendor custom models through DFU.

[Hung Bui]

Hi Illy, 

Let's call the current firmware running on the device is A. The new firmware you compile to do DFU update is B. 
What change to do you make to B ? When it work when it doesn't work ? 

If you add the vendor customized to A when you build A and flash to the device. Do you have any problem when you update the firmware and build B ? 

I don't see the reason why hash value change if you don't change the model/composition data. 

[llly]

Firmware B only modified the version number to check if the DFU was successful.

When adding a custom model, the hash in the upgrade package when building a is already incorrect, rather than obtaining the wrong hash after making other modifications to the firmware

In the simplest terms, adding a custom model will result in incorrect hash values,this no longer requires DFU to verify

The screenshot above shows the upgrade package obtained after adding the manufacturer's custom model. It can be seen that "composition_hash" is 0xdb33f61b,this is an incorrect value

This image is the hash value I manually calculated using the shell command. The correct hash value should be 0xbcce424f

As long as there is a custom model, the problem of obtaining different hash values through two methods will occur, which has nothing to do with the DFU process and is a problem that occurs during construction.Is my description clear enough？