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)

[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

[llly]

Hi

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/known_issues.html#bluetooth_mesh

I found this known issue on my search, but I am not sure if it is related to the problem I encountered

[llly]

Good news. I have found a solution now, which is to manually change the hash value in the upgrade package to the correct hash value, then upload the modified upgrade package to the distributor, and then perform dfu normally. At this point, the img_effect will be BT_MESH_DFU_EFFECT_NONE, and the node upgrade will not become an unprovisioning device after completion

But this is too troublesome, so this problem still needs to be solved

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