View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000138||easycwmp||Help||public||2016-05-27 09:34||2017-11-22 12:08|
|Summary||0000138: Firmware update continues even if file is incomplete|
|Description||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.|
|Tags||No tags attached.|
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
||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.|
||could you please provide your traffic capture and your firmware|
i fixed by comparing the file size before continuing update
if [ "$dl_size" -lt "$size_check" ]; then
common_json_output_fault "" "$fault_code"
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.
|2016-05-27 09:34||superkid||New Issue|
|2016-05-27 09:51||mohamed.kallel||Note Added: 0000479|
|2016-05-30 05:50||superkid||Note Added: 0000480|
|2016-05-30 10:16||mohamed.kallel||Note Added: 0000481|
|2016-06-17 09:32||superkid||Note Added: 0000485|
|2017-11-22 12:08||hmh||Note Added: 0000827|