problem with size of time_t on several 64bit ARCHS/OSes
Joerg.Pulz at frm2.tum.de
Mon May 15 18:17:21 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
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-22.214.171.124 | i386 | 4
Linux-126.96.36.199 | 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
#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
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
The time is in units of seconds, and is specified as a 32-bit
The code for this option is 51, and its length is 4.
Code Len Lease Time
| 51 | 4 | t1 | t2 | t3 | t4 |
Any comments are much appreciated.
The beginning is the most important part of the work.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)
-----END PGP SIGNATURE-----
More information about the dhcp-users