[PATCH 2/2] dhcpc: Allow to specify request-timeout during initial request transmission

Denys Vlasenko vda.linux at googlemail.com
Fri Mar 4 15:47:36 UTC 2016


On Thu, Mar 3, 2016 at 6:50 PM, Hans Dedecker <dedeckeh at gmail.com> wrote:
>> > RFC2131 paragraph 3.1 states the client should retransmit the DHCP
>> > request message enough times to give adequate probability of contacting
>> > the server without causing the client to wait overly to long before
>> > giving up; as an example a total delay of 60 seconds is given.
>> > The udhcp client implementation allows to tweak the number of request
>> > messages via the -t option; however if -t option is set to 0 so the
>> > the client keeps sending discover messages it will get stuck in the
>> > requesting state after an offer if no DHCP ack or nack message is
>> > received.
>>
>> How about the solution of "don't do that then"?
>> Help text doesn't even document that "-t 0" is a valid usage.
>
> The option "-t 0" is used in some cases; eg on OpenWRT the udhcpc is started
> in such way as you want the client to keep sending dhcp discover messages in
> case the DHCP server in the wan network is not responding whatever the
> reason may be.

I don't understand. The same happens without -t0, right? udhcpc sends three
discover packets, and if it gets no response, it runs "leasefail",
waits 20 seconds,
and sends new three discover packets (unless -n or -q is used).
There is -A SECS option if 20 seconds is too long for your tastes.

> If the client receives an offer from a server and follows this up by sending
> a request; it could stay in the requesting state if no ack or nack message
> is received from the server. As an example we have hit this issue when DHCP
> ack message were dropped by an intermediate device; as a result the client
> was not recovering as it kept sending request messages forever. Therefore I
> proposed this patch so the client is kept in the requesting state for a
> configurable amount of time.
> You could argue start the dhcp client with -t followed by a non zero number;
> but as you want the client to send enough discover messages you will chose a
> big number. This will result again into a long timeout in the requesting
> state if no nack/nack is received before the client switches to the
> selecting state.

Just don't specify -t at all, use defaults?


More information about the busybox mailing list