problem with size of time_t on several 64bit ARCHS/OSes

[Joerg Pulz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

since dhcp-3.0.4 there are serious problems with the size of OPTION 51 (IP 
address lease time) with dhcpd running on !32bit ARCHS.
Some tests showed the following for 3.0.4 on an amd64 system running 
FreeBSD:
OPTION:  51 (  8) IP address lease time      86400 (24h)

This is for the same system running dhcpd 3.0.3:
OPTION:  51 (  4) IP address lease time      86400 (24h)

So there is an obvious difference between the IP address lease time in 
the DHCPOFFER between 3.0.3 and 3.0.4 on this ARCH/OS combination.

I've investigated this a little bit further and came to the following 
list, verified by using sizeof(time_t) on several ARCHS and OSes

OS		| ARCH		| sizeof(time_t)
- ----------------+---------------+---------------
FreeBSD		| i386		| 4
FreeBSD		| pc98		| 4
FreeBSD		| alpha		| 4
FreeBSD		| powerpc	| 4
FreeBSD		| amd64		| 8 !
FreeBSD		| ia64		| 8 !
FreeBSD		| sparc64	| 8 !
DragonflyBSD	| i386		| 4
DragonflyBSD	| amd64		| 4
NetBSD		| i386		| 4
NetBSD		| amd64		| 4
Linux-2.6.16.13	| i386		| 4
Linux-2.6.16.13	| x64_64	| 8 !
OSF1 V4.0	| alpha		| 4
OSF1 V5.1	| alpha		| 4
SunOS 5.9	| sparc64	| 4
MacOS-X		| powerpc	| 4

Unfortunately, I've no access to other ARCH/OS combinations, there maybe 
more with 8 bytes length of time_t.

The main fact is, that the current ISC dhcp distribution does not deal 
with the different size of time_t on the various ARCH/OS combinations.

I tested several clients with the server running on FreeBSD amd64 using 
dhcpd version 3.0.4, to see how the clients do react on the wrong size of 
the OPTION 51 (8 bytes).
I got no problems with clients running on various Linux distributions and 
clients used on the *BSD systems.
Unfortunately, Windows (at least XP) seems to be very strict and ignores 
the DHCPOFFER completely.
As a very quick hack, i changed the "includes/cf/freebsd.h" file from
#define TIME time_t
to
#define TIME u_int32_t
and recompiled everything.
Beside some warnings during the build, because gmtime() and time() expect 
64bit time_t arguments and get the 32bit u_int32_t now, everything went 
fine.
I tried the Windows XP clients again and now the patched dhcpd offered the 
IP address lease time with a length of 4 bytes, and XP is happy again.

I've not tested how this will affect the failover situation between 
systems with 4 bytes and 8 bytes length of time_t. It may be broken too, 
but I'm unsure.

The main question for me is now, should the OS vendors fix their 
definition of time_t (not sure what POSIX says about the size of time_t) 
or should the different size be handled in th ISC dhcp distribution?

At least the RFC is very clear about the size of OPTION 51
- -snip
    The time is in units of seconds, and is specified as a 32-bit
    unsigned integer.

    The code for this option is 51, and its length is 4.

     Code   Len         Lease Time
    +-----+-----+-----+-----+-----+-----+
    |  51 |  4  |  t1 |  t2 |  t3 |  t4 |
    +-----+-----+-----+-----+-----+-----+
- -snip

Any comments are much appreciated.

regards
Joerg

- -- 
The beginning is the most important part of the work.
 				-Plato
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEaMW0SPOsGF+KA+MRApFKAJwPNmV0DvXS6eh1ez5WmcGmTrMyJACfWO1e
dJDtAs1d3pobZxp9Ub0Gqo8=
=2d7r
-----END PGP SIGNATURE-----