We have identified a problem in an implemention of the WIDE dhcp client
in a third party product that can potentially cause severe disruption
of the operation of the ISC dhcp (Version 2, Patchlevel 27) server.
We do not have access to the source code for the third-party
implementation, so the following analysis is speculation based
on the symptom we have seen.
If the client does not explicitly request a rebinding time
(T2), the WIDE client incorrectly calculates a value for
the rebinding time. Because of the bug, an incorrect cast,
the time stored by the client can be shorter than the renewing
time. If this occurs, it is detected when T1 expires, and the
client validates its lease. Since neither T1 or T2 are delivered
by the ISC 2.0pl27 server unless they are requested, the client will,
if the lease is sufficiently long, discover that its T2 is less
than its T1 - both of which it has calculated. When this occurs,
it appears that the client advances state to "rebinding", and makes the
same discovery.
In the client implementation from our vendor, this results in an
endless loop within the "rebinding" state, which causes a stream of
broadcast DHCPREQUESTs to be sent by the client. There
is no delay between successive broadcasts. It is the fact
that the state is non-terminating, coupled with the fact that
the client itself has miscalculated the renewal and rebinding
time, that can cause disruption of the operation of the server.
Our vendor has already fixed their product.
We do not know whether the WIDE client as distributed by the
WIDE Project exhibits this problem. It is known that our
vendor ported the WIDE client to their environment, and
that the incorrect cast was not corrected during the port.
I downloaded the latest WIDE code today, and found that this
problem is present in Version 1.4.0p6, released on 3 March
1999. The patch attached to this message is against that
release from the WIDE Project.
We have tested the change supplied by our vendor against
the ISC dhcpd 2.0pl27, and the problem appears to be
resolved. We have also verified that the Microsoft DHCP
server (NT4.0/Service Pack 4) supplies T1 and T2, even
though it is not being requested by the client, so
the miscalculation does not occur.
If you are using the WIDE client, or are using a product
containing an implementaion WIDE dhcp client, you are urged to
either contact the vendor or apply the attached patch.
Jim
--
Jim Watt [EMAIL PROTECTED]
PE Corporation Voice (desk): +1 408 577 2228
PE Informatics Division Fax: +1 408 894 9307
3833 North First Street Voice (main): +1 408 577 2200
San Jose CA 95134-1701
*** dhcp-1.4.0p6/client/dhcpc_subr.c.orig Fri Jan 1 06:21:08 1999
--- dhcp-1.4.0p6/client/dhcpc_subr.c Wed May 12 16:39:56 1999
***************
*** 542,548 ****
}
if (parameter->dhcp_t2 == 0) {
double tmp = (double) parameter->lease_duration * 0.875;
! parameter->dhcp_t2 = (unsigned short) tmp;
SETBIT(parameter->got_option, DHCP_T2);
}
--- 542,548 ----
}
if (parameter->dhcp_t2 == 0) {
double tmp = (double) parameter->lease_duration * 0.875;
! parameter->dhcp_t2 = (unsigned long) tmp;
SETBIT(parameter->got_option, DHCP_T2);
}
