How long should a client wait for a DHCPOFFER?

[Aaron Bennett]

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!
>
http://www.faqs.org/rfcs/rfc2131.html

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