nRF connect crashes when device reports 0 bytes for DFU partition

[plaes]

When firmware accidentally reports 0 bytes available for DFU partition, then nRF connect seems to be simply crashing.

This happens with nRF connect 4.28 and (2.26 as well).

I'm developing a custom Rust-based firmware which is using DFU over BLE. When testing with nRF connect, and attempting to push out application.zip, it crashed after the download and validation for the .dat file was complete and nRF-Connect requested to start pushing the actual firmware payload.

Log file from firmware side starts just after *.dat file has been uploaded and its CRC is going to be calculated:

19.497955: TRACE DFU REQUEST Crc
19.497985: TRACE DFU RESPONSE DfuResponse { request: Crc, result: Success, body: Some(Crc { offset: 79, crc: 611744236 }) }
19.632843: TRACE ble evt 87
19.632934: TRACE ble evt 80
19.632965: TRACE gatts write handle=16 data=[4]
19.633026: TRACE DFU REQUEST Execute
19.633087: TRACE DFU RESPONSE DfuResponse { request: Execute, result: Success, body: None }
19.767852: TRACE ble evt 87
19.767913: TRACE ble evt 80
19.767974: TRACE gatts write handle=16 data=[2, 10, 0]
19.768035: TRACE DFU REQUEST SetReceiptNotification { target: 10 }
19.768096: TRACE DFU RESPONSE DfuResponse { request: SetReceiptNotification { target: 10 }, result: Success, body: None }
19.902832: TRACE ble evt 87
19.902893: TRACE ble evt 80
19.902923: TRACE gatts write handle=16 data=[6, 2]
19.903015: TRACE DFU REQUEST Select { obj_type: Data }
19.903106: TRACE DFU RESPONSE DfuResponse { request: Select { obj_type: Data }, result: Success, body: Some(Select { offset: 0, crc: 0, max_size: 0 }) }
18.723419: TRACE ble evt 87
19.803649: TRACE ble evt 17
19.803680: TRACE on_disconnected conn_handle=3
19.803741: TRACE conn 0: disconnected
19.803771: INFO  GATT server disconnected: DisconnectedError

And at this point, nRF connect seems to be crashing due unexpected response where max_size = 0.

[philips77]

Hi, thank you for the bug report. This issue seems to be more related to the DFU library, rather than nRF Connect, so I moved it here.

The crash may come from this line: https://github.com/NordicSemiconductor/Android-DFU-Library/blob/ee04574dcc438bf067505327eebb37018ee908b8/lib/dfu/src/main/java/no/nordicsemi/android/dfu/SecureDfuImpl.java#L508 We're in XXI century and humanity still can't divide by 0.

Fixing this issue is a bit difficult, as there's no clear solution what to do in such case. Should it select the object again, hoping for non-zero value, or abort? Of course, crashing is the worst option.

Anyway, I hope you can fix it on your side, as I'm quite busy with other tasks and this one will have to wait.

[plaes]

Hi, thank you for the bug report. This issue seems to be more related to the DFU library, rather than nRF Connect, so I moved it here.

The crash may come from this line:

https://github.com/NordicSemiconductor/Android-DFU-Library/blob/ee04574dcc438bf067505327eebb37018ee908b8/lib/dfu/src/main/java/no/nordicsemi/android/dfu/SecureDfuImpl.java#L508

We're in XXI century and humanity still can't divide by 0.

Fixing this issue is a bit difficult, as there's no clear solution what to do in such case. Should it select the object again, hoping for non-zero value, or abort? Of course, crashing is the worst option.

Ideally DFU process is aborted and relevant error is bubbled up to the UI as device seems to be unable to accept the firmware.

Anyway, I hope you can fix it on your side, as I'm quite busy with other tasks and this one will have to wait.

Yeah, I already figured this out and "worked it around" from firmware side where I had a typo in the DFU partition length calculation.