EasyCwmp - easycwmp
View Issue Details
0000138easycwmp[All Projects] Helppublic2016-05-27 09:342017-11-22 12:08
0000138: Firmware update continues even if file is incomplete
When we update our devices using acs server and if acs server suddenly stopped, download will be incomplete but firmware update continues and it destroys our devices. Do you have hash code checks before updating the device? Please help.
No tags attached.
Issue History
2016-05-27 09:34superkidNew Issue
2016-05-27 09:51mohamed.kallelNote Added: 0000479
2016-05-30 05:50superkidNote Added: 0000480
2016-05-30 10:16mohamed.kallelNote Added: 0000481
2016-06-17 09:32superkidNote Added: 0000485
2017-11-22 12:08hmhNote Added: 0000827

2016-05-27 09:51   
we do not have code that check the validity of the firmware. I think that the job of the update command.
But I think you can use md5 Checksum check of the OpenWRT firmware before calling sysupgrade. I tihnk the luci page do that before calling the sysupgrade command. I think that you can develop a check function that calculate the firmware checksum and then compare it to the firmware checksum.
Please keep me updated with your advancement and please share your check function if you are going to develop it
2016-05-30 05:50   
But you are checking if the downloaded file matches the correct file size and if it doesn't, you will download it again before proceeding to firmware update right? I just don't understand why it continue to update even if the file is incomplete.
2016-05-30 10:16   
could you please provide your traffic capture and your firmware
2016-06-17 09:32   
i fixed by comparing the file size before continuing update

 if [ "$dl_size" -lt "$size_check" ]; then
        let fault_code=9000+$E_DOWNLOAD_FAILURE
        common_json_output_fault "" "$fault_code"
        /sbin/sysupgrade $DOWNLOAD_FILE
2017-11-22 12:08   
The current lack of proper size checking on the downloaded file before one handles the data to "sysupgrade" is one MAJOR issue in the easycwmp scripts. Fixing it would improve the safety of firmware upgrade operations a great deal...

One can trivially get sysupgrade images with internal checksums in LEDE by enabling the image metadata mode (this is even the default on a few LEDE targets already), but the file format is going to FAIL to detect truncation unless you activate "require metadata" mode for the platform, which breaks backwards compatibility (older images, or images from other openwrt clones/forks won't have been generated with the checksum trailer).

And the underlying platform-specific flash upgrade routines that "sysupgrade" calls are not always good enough to have their own embedded checksums *or* check them, to put it mildly. So, depending on the platform you target, you can get a missflash on truncated files, instead of a clean rejection.