Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: Weaver on July 15, 2018, 06:55:14 AM
-
It is a bit of a pain, the length of time my modem takes to boot. I saw a few things in the CLI manual that made me thing about ways of improving it. The manual I have seems really inaccurate - some commands that I tried were ‘not recognised’, and I entered them very carefully because I used copy-paste from the manual PDF file into Telnet, so no chance of finger trouble misspelling keywords anyway.
One thing is something paragraph that is very garbled about enabling / disabling a testing procedure on usb port hardware at boot time, and it mentions something about slowness but the text is a mess and the ingrish all over the place.
Another thing is concerning groping for ATM VCI values, in a kind of intelligent auto-config routine, which might be really slow for all I know. It looks as if it is the good thing - fixed to VPI/VCI = 38/0 for BT ADSL2 in my case. My config came from AA my ISP, so the basics will be correct, it’s not just based solely on my attempt.
I wonder if anyone knows of any other annoying options which cause delay?
[Remember from the early 80s, the horrible RAM test that some machines did, the original IBM PC might be one example, I forget. Luckily you could turn it off in the sane machines. At work one group had an OS/2 Lan Manager file server which used to do a chkdsk (or the equivalent) on its filesystem every time the box had not shut down cleanly, ie because of a power outage or a crash, and the thing felt like it was taking a fortnight.]
-
With my VMG1312-B10A I always allow for three minutes following a cold-boot.
Looking in my library, I have copies of the --
- CLI Reference Manual Version 1.0
- User's Guide Version 1.0 Edition 3
I suspect you have the same. If not, let me know . . .
-
Quite a few commands mentioned in the manual for the CLI are just unknown by the box itself. Maybe a general piece of documentation got associated with umpteen products, among which some were older, some newer or just modified for some strange reason.
Exactly those same version numbers, for both.
-
Did you login as "admin" or "supervisor"?
At which CLI prompt did you issue the commands? The ZyXEL prompt (" > ") or the BusyBox shell prompt ("~ # ")?
[Duo2 ~]$ ssh admin@AP
admin@ap's password:
> sh
sshd:error:945.113:processInput:599:unrecognized command sh
> Connection to AP closed.
[Duo2 ~]$ ssh supervisor@AP
supervisor@ap's password:
> sh
~ # > CLI exiting now.
Bye bye. Have a nice day!!!
Connection to AP closed.
[Duo2 ~]$
-
The ZyXEL prompt. I have learned something - I was not aware of the distinction and just assumed that there was one shell, not counting the multiple well-known unix contenders, that is.
-
There was something else that I was implying but perhaps my reply was just too enigmatic.
The "supervisor" login is equivalent to "root" in Unix/Linux terms. The "supervisor" account has UID 0 and GID 0.
The "admin" login has lesser privileges; it has UID 100 and GID 1.
Both of those logins can issue commands at the ZyXEL prompt (" > ") but one of them is restricted as to what is allowed.
-
You can also escape the cut down zyxel shell even when logged in as admin not supervisor by entering:
xtm && sh
Have been musing for a while about making a stripped down firmware for just bridge mode use of 1312s & 8924/8324s as they both do take a very long time to boot and in bridge mode there is very little of the original functionality required. I have not had a thorough look at what could be removed, but for example, even with wireless disabled there is a great deal of output in the boot log related to setting up the wireless interfaces. Also the usb sharing services eg samba could be removed, there are several services running to support SIP calling on the 8324 that are of no use. I'm sure there are many more candidates for removal, but whether there is a nice clean way of getting rid of them is another matter. Unfortunately so much of the boot and configuration is hidden away inside of sourceless binaries rather than boot scripts and the like.
Have a look at "/etc/profile". It runs at boot and looks to be responsible for all the pointless wireless set up that happens even with wifi disabled, thats where I'd start disabling things.
Its possible that just removing the executable for other things will work ok, just producing warning in the boot log, for example there are 4 instances of "voiceApp" each consuming 6.5% of available memory currently running on my 8324, maybe just removing it from the firmware will work ok?
Further experimentation required.
-
That is a really excellent idea. It is such a pain, and quite worrying as it takes sooo long that you start to lose faith.
-
Have a look at "/etc/profile". It runs at boot . . .
[off topic]
In the last few lines of the "/etc/profile" file, we can see where basic "/var/passwd" and "/var/group" files are created. That "passwd" file is subsequently modified, later in the boot process.
Here are the lines from the "/etc/profile" file, from my VMG1312-B10A device --
# generate login files
echo "supervisor:3Gnc.CJE1790M:0:0:Administrator:/:/bin/sh" > /var/passwd
echo "root::0:root,supervisor,support,user" > /var/group
Let's look at the second field for the "supervisor" line. I count thirteen characters. That just has to be the output of DES crypt(). Rather than attempting to use a "brute force" method of decrypting it, let's work the other way. A lot of the ZyXEL documentation, for various devices, will show "zyad1234" as the default password for the "supervisor" login. A few lines of C-code were quickly thrown together --
/*
* supervisor:3Gnc.CJE1790M:0:0:Administrator:/:/bin/sh
*
* Compile and link:
*
* cc -lcrypt -o doencrypt doencrypt.c
*/
#define _XOPEN_SOURCE
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
char *key = "zyad1234";
char *salt = "3G";
printf("crypt(\"%s\", \"%s\") returns \"%s\"\n", key, salt, crypt(key, salt));
exit(EXIT_SUCCESS);
}
Compiling and then executing the resultant binary --
[Duo2 ~/tmp/]$ cc -lcrypt -o doencrypt doencrypt.c
[Duo2 ~/tmp/]$ doencrypt
crypt("zyad1234", "3G") returns "3Gnc.CJE1790M"
[Duo2 ~/tmp/]$
Point proven. :)
[/off topic]
-
Ah, how satisfying burakkucat!
Unsatisfyingly though it appears this if statement before all of those wlctl etc commands evaluates to true
ReduceTimeFlag=$(cat /proc/nvram/ReduceTimeFlag)
#echo "get ReduceTimeFlag : $ReduceTimeFlag"
if [ $ReduceTimeFlag == "00" ]; then
smd
else
#REPLACE_STRING_IF_SWMDK_BUILD
ifconfig eth0 up
ifconfig eth1 up
...
So no boot time savings to be gained there.
-
So no boot time savings to be gained there.
That is unfortunate. :(
Blue-sky thinking (and not suggesting it). Knowing how Weaver just requires a basic modem, one that is inaccessible as a discrete device from the public (WAN) side & with protected access as a discrete device from the private (LAN) side, which acts as an ATM end-point passing Ethernet frames to/from the private (LAN) side, the stock ZyXEL firmware image could be reduced to a fraction of its current size.
-
Burakkucat is of course quite correct.
-
So I had a go chopping things out of makefiles in the firmware build this evening, and its remarkable the amount of stuff you can remove and still have a booting functional modem. The vast majority of things removed have little to no impact on boot time though, with the exception of iptables. Removing it saves around 17 seconds on the boot. My device takes ~ 1m 18s from power switch to solid green light, and without iptables 1m 1s.
Its probably a bad idea to remove, but when we're talking about a device thats fairly segregated on the network with no access to the internet is it really that bad? Removing it doesnt open any more ports or anything, it just stops packets to non open ports being dropped. Running an nmap scan on a device with iptables and without the only difference is the time it takes as the iptables device hinders the port scan by dropping requests.
I dont think I'd lose sleep over not having it, but I guess for only a 22% reduction you could argue its not worth it.
-
Is that with WIFI stuff removed too?
-
The wifi stuff I mentioned previously contained in "/etc/profile" does not get run it turns out, and if you remove all wlan capabilities it somehow breaks http and telnet access as doing either invokes a libwl*.so of some sort.
-
I wonder if a better compiler or more aggressive optimisation switches would help boot time. The compiler will be the best available (MIPS?) and probably the switches will probably be right. Also for all I know it could be i/o limited or limited by the speed of RAM. RAM could be cold too. So I am not at all hopeful, switches would be the only thing where there might be a chance.
It is incredible the amount of time it takes. My Firebrick boots in well under seven seconds.
-
Yes but that makes the Firebrick incredibly fast, not the Zyxel incredibly slow.
The average consumer grade modem/router boots far closer to the Zyxels boot time than the Firebricks.
-
Agree that the firebrick is the outlier here, but even for normal consumer stuff the zyxel boxes are at the slow end.
I had a look at using a different toolchain, downloaded the "Codescape" package from MIPS, but on inspection the layout the differences between it and the one supplied by zyxel would mean an awful lot of hunting through Makefile spaghetti or meticulously renaming things in the Codescape package.
The supplied one is uClibc, which from looking at:
https://www.linux-mips.org/wiki/Toolchains
appears to be the most complete if not the most optimised. I know compiler optimisation is some dark magic, but I doubt there are serious benefits between solutions to a problem as well explored as C/C++ compilers.
Had some fun poking around with "make menuconfig" on the kernel, lots of very specific broadcom options there, one thing of note was a DSL GINP RETX option which was completely disabled... this must be of no consequence as GINP certainly works without it, but weird that there is unused kernel support for it.
Trying to build after making changes to the kernel config somehow managed to break the build environment on my VM... fun! Some changed env variable or something maybe, couldn't seem to reverse it even after removing everything related to the build and setting it up again. Was good to refresh how to create it in a new VM though, it really is just a few steps.
So yeah, probably wont be playing with kernel configs much more, but may stick with removing iptables on my own firmwares.
-
>doubt there are serious benefits between solutions to a problem as well explored as C/C++ compilers.
On the contrary, sort-of, speaking as an assembler language programmer the differences between C or C++ are both small and large depending on circumstances. There has been a huge amount of very advanced new technology recently and in some respects compilers are improving enormously. On some run-of the-mill stuff good compilers are fairly similar especially if exotic settings are nit investigated. But some new compilers have new tricks that will be killers in the right circumstances. Writing a decent backend is really hard nowadays because the standard is so high and doing a good job of handling parallelisation and SIMD is got easy. Also optimisations based in cold-got cache awareness are getting more and more important as RAM becomes a worse embarrassment by the year.
I think you made the right decision. My intuition is that the gains to be had on a processor such as MIPS are probably less than those available on x86 or x64.
-
@burakkucat can you look at it?
echo "admin:8wZAynnnSPWmU:0:0:Administrator:/:/bin/sh" > /var/passwd
-
@burakkucat can you look at it?
#echo "supervisor:3Gnc.CJE1790M:0:0:Administrator:/:/bin/sh" > /var/passwd
echo "admin:8wZAynnnSPWmU:0:0:Administrator:/:/bin/sh" > /var/passwd
echo "root::0:root,supervisor,support,user" > /var/group
I've looked at it and see nothing that is relevant to Weaver's topic "ZyXEL VMG 1312-B10A - long time to boot up". You really should start your own topic with a suitable subject line and not hijack existing topics.
Of the three lines you have shown, the first is commented out and, thus, is not executed. The second line creates a minimal passwd file in the /var/ directory. The password string has been encrypted with the descrypt() function and therefore cannot exceed a maximum length of eight characters. The third line creates a minimal group file in the /var/ directory.
The string 8wZAynnnSPWmU is just the DES encrypted representation of 1234. I.e the admin "password" is 1234.