Is any initial configuration needed before easyddup works? Or does it have to be used on a router (gateway mode), and not a WAP (router mode)? Currently it is not showing any available updates even though there should be:
Code:
root@R6900:/opt/easyddup# ./easyddup.sh -c
New versions available after currently installed build (47925): 0
Also, a (fortunately) dry run did not list builds as expected and instead just shows a url:
Code:
root@R6900:/opt/easyddup# ./easyddup.sh -n
Burn of firmware will not be done.
All dd-wrt upgrade builds available online for 2022
1) http://www.dd-wrt.com
Current build: 47925
Select a build to install (or Q): 1
sh: t.com: out of range
Selected http://www.dd-wrt.com
Files in build http://www.dd-wrt.com for Netgear R7000
1) www.dd-wrt.com
Select a firmware file to install (or Q): 1
Selected www.dd-wrt.com
Build not in local cache or -f option, downloading...
Downloading https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2022/http://www.dd-wrt.com/netgear-r7000/http://www.dd-wrt.com ...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 415 100 415 0 0 681 0 --:--:-- --:--:-- --:--:-- 681
Downloaded file OK.
WARNING THIS COULD BRICK YOUR ROUTER!!!
File to burn: ./fwcache/http://www.dd-wrt.com/netgear-r7000/www.dd-wrt.com
Erase nvram y/n ? n
Save user settings restore point y/n ? n
Burning ./fwcache/http://www.dd-wrt.com/netgear-r7000/www.dd-wrt.com
WARNING: DO NOT INTERRUPT...
WAIT FOR BURN TO COMPLETE (at least 5 minutes)
Skipping firmware burn.
Skipping reboot.
Thankfully it was a dry run because "burning" that would not be good.
Maybe it's a bug because there are no new builds available so far for 2022? That directory does not yet exist on the dd-wrt server.
EDIT: After specifying the year with "-y 2021" it finds the newer build as expected and the url is valid, so it seems like the issue is an unhandled edge case.
Improve error checking of case where no builds exist yet this year. Thanks @fizikz for the detailed report. I remember specifically fixing this in January two years ago but I guess the web server responds differently now.
doing too many nvram changes before the first reboot is not recommended
Why is this, and since when? I never did reboots after flashing if there were no issues, but then again I also don't typically clear nvram.
How about adding some variables to easyddup-vars.ini to at least have SSH configured right away? That way, after a firmware change where nvram is erased, one can just SSH into the router and run nvram-restore.sh and hopefully everything will be back.
I think sshd_enable, sshd_rsa_host_key, sshd_authorized_keys would be the minimum for SSH with public key authentication? I wouldn't mind also having sshd_passwd_auth which I like to keep disabled, but that's not a minimum and I guess it can wait a few seconds.
The GUI reboots immediately after flashing. The CLI instructions say to reboot as the final step. Kong's ddup used to reboot on the same line of code as the flash. You are running from RAM a software version that no longer exists on the router. Some have questioned the safety of easyddup storing the new firmware on USB (never a problem so far). I'm not a router person so you could create a thread asking about rebooting after flash.
Add the SSH variables (even sshd_passwd_auth) to your easyddup-vars.ini so you can just SSH into the router after reboot. After a month or several upgrades if all goes well, report back and I'll put it into the distribution so everyone benefits.
Same thing for useful missing GUI variables you add to nvram-dd-wrt.ini restored manually by running nvram-restore-latest.sh. Settings you care about and are working/tested I'll put it into the distribution.
Oh, nevermind, I was confused. I thought you meant it needed a second reboot before configuring settings. I considered the first reboot as part of the upgrading process, since the new firmware is not running before that. When upgrading from the webui, there isn't even a choice in the matter. Of course the whole issue here is about clearing or setting nvram variables before rebooting the first time after flashing. Silly me.
I'll add the ssh variables and report any findings, but I don't expect to be clearing nvram at all, or even upgrading firmware too frequently. "If it ain't broke don't fix it." This setup is to be prepared if/when it is broke and needs a reset.
Btw, there are mentions in the QuickStart.txt to merlin, which can be confusing. Those are vestiges of the original nvram backup tool? Plus, some of the terminology is foreign to me such as "code level" (firmware/build release/version?)
Also, the terminology of "user settings restore point" is a bit confusing to me. Reading the code, that selection is calling nvram-save.sh, so I would suggest avoiding the "restore point" phrase. Maybe just calling it nvram save or backup settings would be clearer.
And the -w "wipe cache items" was confusing to me at first though it makes sense after reading the code. I would perhaps call it "delete/wipe previously downloaded firmware cache" or similar.
Fix counting of the number of newer versions available in cases where your current build is not found in the year being processed. Thanks @fizikz for the report.
Helps if e.g. your installed build is from 2021 and year 2022 is being processed. Also helps if you are running your own build number that doesn't correspond to any official build number so it will never be found regardless of year.
Note that the count is only for the year being processed so if there are 3 newer builds in 2022 it will say 3 even if some 2021 builds are also newer than what you are running.
PS. Sorry, no documentation updates since we're in maintenance mode.
Thanks @yoyoma2 I can confirm "./easyddup.sh -c" now works correctly.
Note that customized easyddup-vars.ini files get overwritten when upgrading easyddup. It might be nice if easyddup included it as a .sample file as it does with a few other .ini files. Though that might need some rewriting to avoid breaking out of the box functionality. Right now I'll have to remember to back mine up (eg. easyddup-vars.ini.bak) and then copy it back to the correct filename after each upgrade.
The basic settings and restore point settings are now distributed as sample files (easyddup-vars.ini.sample & nvram-dd-wrt.ini.sample) and are only copied in place at runtime if not already present. This avoids clobbering user customizations during upgrades. Thanks to the good suggestion from @fizikz.
@lnbacpjnb: You're welcome. It's actually nice to hear a thank you.
Fantastic improvements! Thanks for being so responsive @yoyoma2
Do you know if the download link url changes when new versions are uploaded? I put the download and installation steps into a little script in the parent directory to make upgrades even easier, but it depends on a fixed url:
What do you think about implementing a check for available updates to easyddup, or even the possibility to update itself? If it's too much hassle, no worries, it's easy enough to do manually.
I never noticed if the download link remains the same after a new version is uploaded. I do use the "Upload new version" button as opposed to deleting and adding the attachment so it may preserve the link. Let us know if your script still works after the next upgrade.
As for automated upgrades easyddup doesn't really use a version number other than printing one in the help and log file but it has never been changed.
Crazy idea: If your easyddup directory is shared with samba, you could delete .preventUpdate in there from your PC. Your update script in a cron job could do nothing if .preventUpdate is there, otherwise upgrade and regenerate .preventUpdate. Not an automatic update but as easy as deleting a file when you see a new version you want.
I never noticed if the download link remains the same after a new version is uploaded. I do use the "Upload new version" button as opposed to deleting and adding the attachment so it may preserve the link. Let us know if your script still works after the next upgrade.
Ok, I'll try to remember.
yoyoma2 wrote:
As for automated upgrades easyddup doesn't really use a version number other than printing one in the help and log file but it has never been changed.
Crazy idea: If your easyddup directory is shared with samba, you could delete .preventUpdate in there from your PC. Your update script in a cron job could do nothing if .preventUpdate is there, otherwise upgrade and regenerate .preventUpdate. Not an automatic update but as easy as deleting a file when you see a new version you want.
My thought was not so much about automated upgrades but a similar functionality to "easyddup -c" but for easyddup itself. Kind of like "easyddup -sc" to self-check for updates, and possibly "easyddup -su" to self update. Hopefully with better flags.
yoyoma2 wrote:
Gitlab/github came up on page 7 and even page 2 of this thread... sorry still too much hassle.
In a way it might be a bit of hassle, but in another way it could reduce hassle by allowing others to merge their suggestions instead of having you do everything. Also easier version control, issue tracking, etc.
@yoyoma2 I think you had mentioned you'd be ok with someone creating a repo and adding you as a maintainer? @IONK maybe you'd be interested to do that?