I decided to see if I could see why RUC was stopping at 80% whenit is run against my old Hercules DSL router (ar7).
In my case the cm_cli_tty binary is not on the router - so RUC puts a version on it.
This is done by the telnet session issuing a wget against the RUC built-in web server (port 5000).
The wget suceeds but whatever should happen next ... doesn't.
My guess is that RUC would then do a
chmod +x cm_cli_tty
so - perhaps it is waiting for a particular response from wget that never appears.
If I do the chmod I can then run the new /var/cm_cli_tty - so does look like the wget worked.
Doing the same thing by hand shows that when the wget completes then all that comes back over the telnet session is the "#" prompt on newline.
# pwd
/var
# rm cm_cli_tty
# ls
cache flash lock proc tmp var
dev lib log run upgrader webport
# wget
http://192.168.38.4:5000/cm_cli_tty
# ls
cache flash log tmp webport
cm_cli_tty lib proc upgrader
dev lock run var
The wget on this system identifies itself like this:
# wget
BusyBox v0.61.pre (2007.08.14-07:24+0000) multi-call binary
Usage: wget [-c|--continue] [-q|--quiet] [-O|--output-document file]
[--header 'header: value'] [-Y|--proxy on/off] [-P DIR] url
I see a few references here opn the forum to things sticking at 80% - and the usual response is to suggest disabling the backup function in RUC - which does not clear the problem.
I will try to run the other firmware checker tool later - but perhaps someone with the source code to RUC could check to see what it expects after issuing the "wget"?