On Thu, Mar 3, 2016 at 2:17 AM, Denys Vlasenko <[email protected]> wrote:
> On Thu, Feb 18, 2016 at 12:27 PM, Hans Dedecker <[email protected]> > 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. 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.
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
