If there's no portable way for the script to automatically figure out the directory name for revisions for all vendors, how about a new board or revision argument eg:
Perhaps one of those board numbers identifies the the revision but nothing obvious. Does dd-wrt itself display the revision in Status Router or Sys-Info? If not, I'll add an argument.
Tested as well as I could with a router that doesn't need a revision argument.
If you use an email notification script based on the sample checknewversion.sh you'll need to edit that script where it calls easyddup.sh to add the -r.
The warning you suggested is in the -h and in the Readme.txt.
Also added a check to fail if no files are found instead of asking the user to pick from an empty list.
Perhaps one of those board numbers identifies the the revision but nothing obvious. Does dd-wrt itself display the revision in Status Router or Sys-Info? If not, I'll add an argument.
Status page doesn't show rev number
yoyoma2 wrote:
New version posted in OP.
Changes:
Add -r option as discussed. Example:
easyddup.sh -r reva
Tested as well as I could with a router that doesn't need a revision argument.
If you use an email notification script based on the sample checknewversion.sh you'll need to edit that script where it calls easyddup.sh to add the -r.
The warning you suggested is in the -h and in the Readme.txt.
Also added a check to fail if no files are found instead of asking the user to pick from an empty list.
I've added this to the startup script to save my lazy a**
First attempt at a config file to avoid some mundane questions. The comments and variable names in the new file easyddup.ini.sample should make it self explanatory.
What happens to the load average on dd-wrt during the download? Https/SSL does use some CPU. You could echo the curl command run by easyddup and paste it on a pc and see if it's any faster.
I have no plans for easyddup but tweaking a few lines as recently is ok. I mostly use local builds and easyddup is for official builds. I still use the email notification feature to know how far behind I'm falling.
If anyone wants to put it up on gitlab/github and improve it that would be great. Hopefully I could be a co-maintainer.
What happens to the load average on dd-wrt during the download? Https/SSL does use some CPU. You could echo the curl command run by easyddup and paste it on a pc and see if it's any faster.
Stuck the multipart script you found into easyddup.sh. You must enable it with the new easyddup.ini keyword EDDUP_USE_MULTIPART and set it to the number of parts to use (script was hardcoded to 20). It seems faster to me.
Just to increase our confidence, without burning, try with and without multipart and run md5sum on both files to confirm it's the same.
Stuck the multipart script you found into easyddup.sh. You must enable it with the new easyddup.ini keyword EDDUP_USE_MULTIPART and set it to the number of parts to use (script was hardcoded to 20). It seems faster to me.
Just to increase our confidence, without burning, try with and without multipart and run md5sum on both files to confirm it's the same.
Suggestions:
- because BS didn't include MD5 in his releases, it's better to have a very simple check on the file size after combining all parts (and also check the return code of each curl process?)
- add option to specify where to store the parts: I think it's (marginally?) faster to store the parts on RAM disk, then redirect the output file of the combine command to the fwcache folder. This may not be possible for devices with small amount of RAM, so it's up to you to consider if it's worth to implement.
- unfortunately the built-in progress bar of curl cannot be used any more, hopefully someone can come up with another way to display the progress (maybe checking the size of each part while the download is ongoing?) _________________ ▫ RSS feed for DD-WRT releases (2023): https://politepol.com/fd/bdQnjdZgyaln
▫ easyddup - A simple upgrade/downgrade utilityby yoyoma2--- as featured in 📌 List of reference threads, how-tos, and otherwise (Moderator's Pick 🌟)
Since that multipart script stores temp files in the current directory, an alias such as this could do the trick.
alias update='cd /tmp ; /opt/easyddup/easyddup.sh -r reva ; cd -'
with this alias I can't send additional params like update -f -n , and because it's already saved in the ramdisk, I'm happy without cd
yoyoma2 wrote:
Is it fast with multipart now? Then the progress status doesn't matter as much. I can't do more than tweak a few lines.
without multipart it takes more than 90sec to complete. with multipart it can finish as fast as within 30sec.
Do you mind if I suggest a way to clean up the duplicated nvram backup files?
yoyoma2 wrote:
What's the smallest number of parts that's still fast enough? I'll make that the default in the sample ini file.
for me i'm ok with 16. probably it depends on the FW size, CPU speed and internet connection speed.
