[BusyBox] DHCP Client fixes

Joshua Jackson busybox at vortech.net
Sat Dec 6 21:02:40 UTC 2003


On Saturday 06 December 2003 03:51, Rob Landley wrote:
> On Saturday 06 December 2003 10:52, Joshua Jackson wrote:
> > On Friday 05 December 2003 23:56, Rob Landley wrote:
> > > On Friday 05 December 2003 13:53, Joshua Jackson wrote:
> > > > - Switched from using time(0) to calculate the passage of time to
> > > > using the system uptime counter from the sysinfo() call. This fixes
> > > > problems when the network is brought up before a timesync or time
> > > > change is performed that causes a skew in timeout values.
> > >
> > > Keep in mind that "uptime" doesn't advance during a software suspend.
> > > (2.6 feature).  Maybe this is the behavior you want, but it does mean
> > > that dhcp won't automatically request a lease renewal when the system
> > > comes back up. (You'll have to thump it from a suspend script...)
> >
> > Resetting the network should (IMO) be part of bringing a system back out
> > of suspend. Either way there are time skew problems, but the fact that
> > the network needs to be brought up on most systems to hit an NTP host and
> > this process is often cron scripted on production systems, using the
> > uptime seems the lesser of two evils to me.
>
> The need to hit an ntp host is due to a continuing bug in 2.6, one which
> they said they'd patched but it didn't fix it.
>
> (And you don't need to hit ntp.  I fix it with hwclock --hctosys.  The
> battery backed timer knows what time it is, but the value in ram that's
> updated by the timer tick gets snapshotted with the rest of ram...)

True. After a successful NTP sync I always issue an hwclock command to write 
it to the hardware. In some of the smaller, embedded devices I have been 
working with, the internal clock doesn't seem to home time well. I guess a 
command line switch could be added to use either value.

Almost all of the work I am doing with busybox is on small, embedded systems 
where suspend is not even an option.

> > > Also, do you handle uptime wrapping on 32 bit systems?  (Is this still
> > > an issue?)
> >
> > Well, if you leave your system up for more than 2,147,483,648 seconds (or
> > roughly 68 years), it will become a problem. The uptime counter is a
> > signed 32 bit integer, so at least 31 bits would be significant or 2^31
> > seconds.
>
> The uptime counter is in jiffies, not in seconds.  When jiffies were
> 100/second it used to be something like 400 days, and now that they're 1000
> it's just under 25 days.  In python: (2**31)/(1000*60*60*24.0) gives
> 24.855...  ALthough I think it moved to signed, so you've got closer to 50
> days.
>
> Still, I could see a workstation going that long without rebooting. 
> Certainly something like a linksys router...

According to the sysinfo() man page, the structure is as follows:

              struct sysinfo {
                   long uptime;             /* Seconds since boot */
                   unsigned long loads[3];  /* 1, 5, and 15 minute load 
averages */
                   unsigned long totalram;  /* Total usable main memory size 
*/
                   unsigned long freeram;   /* Available memory size */
                   unsigned long sharedram; /* Amount of shared memory */
                   unsigned long bufferram; /* Memory used by buffers */
                   unsigned long totalswap; /* Total swap space size */
                   unsigned long freeswap;  /* swap space still available */
                   unsigned short procs;    /* Number of current processes */
                   unsigned long totalhigh; /* Total high memory size */
                   unsigned long freehigh;  /* Available high memory size */
                   unsigned int mem_unit;   /* Memory unit size in bytes */
                   char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding for 
libc5 */
              };

I am using the "uptime" portion of the structure. From personal testing, the 
returned value is counting seconds and the leases are renewing at proper 
intervals.

Is the structure returned by a 2.6 kernel different? If so, the "uptime" 
command in the props for busybox is also going to be wrong as it assumes 
seconds:

        sysinfo(&info);

         updays = (int) info.uptime / (60*60*24);
        if (updays)
                printf("%d day%s, ", updays, (updays != 1) ? "s" : "");
        upminutes = (int) info.uptime / 60;
        uphours = (upminutes / 60) % 24;
        upminutes %= 60;
        if(uphours)
                printf("%2d:%02d, ", uphours, upminutes);
        else
                printf("%d min, ", upminutes);


--
Joshua Jackson
Vortech Consulting
http://www.vortech.net




More information about the busybox mailing list