On Fri, Mar 4, 2016 at 4:47 PM, Denys Vlasenko <[email protected]> wrote: >> 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?
OTOH you are right, -t0 behavior is pathologic. I think the way out is to not use discover_retries counter for "select" packets. Help text does not promise that. I propose that the number of "selects" to be hardcoded to be 3 for now. If someone would explain a scenario when it truly needs to be variable, we can do that. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
