Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

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.]

[burakkucat]

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 . . .

[Weaver]

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.

[burakkucat]

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 ~]$

[Weaver]

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.

[burakkucat]

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.

[johnson]

You can also escape the cut down zyxel shell even when logged in as admin not supervisor by entering:

Code: [Select]

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.

[Weaver]

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.

[burakkucat]

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]

[johnson]

Ah, how satisfying burakkucat!

Unsatisfyingly though it appears this if statement before all of those wlctl etc commands evaluates to true

Code: [Select]

  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.

[burakkucat]

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.

[Weaver]

Burakkucat is of course quite correct.

[johnson]

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.

[banger]

Is that with WIFI stuff removed too?

[johnson]

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.