On Thu, Mar 3, 2016 at 6:50 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.
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? _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
