How long should a client wait for a DHCPOFFER?
frances.cincinattus at gmail.com
Fri Oct 13 18:57:40 UTC 2006
On 10/13/06, Aaron Bennett <abennett at clarku.edu> wrote:
> Frances Albemuth wrote:
> > Hi all,
> > This isn't so much an issue or question specific to the ISC DHCP
> > server, but more a general question. I'm having trouble finding an
> > authoritative source or even a general understanding regarding
> > guidelines for how long a client should wait to hear a DHCPOFFER. I'm
> > dealing with a particular vendor of consumer class routing devices
> > whose DHCP client implementation isn't tolerant of any delay (e.g.
> > DHCP relay, a la Windows 95, I suppose). I would like to have
> > something to direct them to in hopes of persuading them to modify the
> > wait time in their next firmware release.
> > Thanks!
> I think the relevant section is:
> > The client times out and retransmits the DHCPREQUEST message if the
> > client receives neither a DHCPACK or a DHCPNAK message. The client
> > retransmits the DHCPREQUEST according to the retransmission
> > algorithm in section 4.1. The client should choose to retransmit
> > the DHCPREQUEST enough times to give adequate probability of
> > contacting the server without causing the client (and the user of
> > that client) to wait overly long before giving up; e.g., a client
> > retransmitting as described in section 4.1 might retransmit the
> > DHCPREQUEST message four times, for a total delay of 60 seconds,
> > before restarting the initialization procedure. If the client
> > receives neither a DHCPACK or a DHCPNAK message after employing the
> > retransmission algorithm, the client reverts to INIT state and
> > restarts the initialization process. The client SHOULD notify the
> > user that the initialization process has failed and is restarting.
> Aaron Bennett
> Sr. Unix Systems Administrator
> Clark University ITS
> abennett at clarku.edu | 508.781.7315
More information about the dhcp-users