udhcpc is disrespecting --retries, unless -n is passed as well

John Spencer maillist-busybox at barfooze.de
Wed Aug 7 00:08:09 UTC 2013


On 08/07/2013 01:04 AM, Michael D. Setzer II wrote:
> On 6 Aug 2013 at 17:40, John Spencer wrote:
>> On 08/06/2013 12:08 PM, Michael D. Setzer II wrote:
>>> On 6 Aug 2013 at 9:44, John Spencer wrote:
>>>
>>> Date sent:	Tue, 06 Aug 2013 09:44:04 +0200
>>> From:	John Spencer<maillist-busybox at barfooze.de>
>>> To:	busybox<busybox at busybox.net>
>>> Subject:	udhcpc is disrespecting --retries, unless -n is passed as
>>> well
>>>
>>>> udhpc is looping forever witout respecting the number of retries
>>>> given. only passing -n makes it exit after the max number of
>>>> retries.
>>>>
>>>> this is pretty counterintuitive. took me about 2 hours to track
>>>> down this bug because all the funky CFLAGS and LDFLAGS used by BB
>>>> even when doing a debug build make gdb behave very odd and the
>>>> function has a huge loop with dozens of gotos and possible exits. i
>>>> had to explore the buildlogs and rip out the commands executed to
>>>> strip all those debug killer CFLAGS away.
>>>
>>> I use the udhcpcd -n -t 8 -T 5 -i $variablewithinterface -s
>>> ./udhcpc.sh
>>>
>>> Originally, I just had the -n -i -s options, but had a user that
>>> wasn't gettting the ip address on the initial boot process. Hoping
>>> this additional options will make it more robust.
>>
>>
>> now we have the opposite situation: a user (me) cannot even login to
>> his machine because udhcpc spawned from init loops forever instead of
>> exiting after 3 tries as it should. there is nothing at all that
>> indicates wtf is happening there and why udhcpc is ignoring the passed
>> option. the retries option help text does not explain that it only
>> works in combination with -n.
>>
>> since the option "-t 0" (0 retries means indefinite retries) has been
>> added recently (see commit 1c7a58dfb82ea04c525e0c19f94f2d800dee99e3 by
>> openwrt folks), having the -n option seems redundant. so removing -n
>> and adding a hint about the -t 0 switch instead seems like the best
>> solution.
>>
>
> My understanding is that the udhcpc is set to run in a loop without
> the -n because the IP is not permanent. You get the lease for a
> fixed amount of time, and it has to be renewed occassionally, so
> that is why it needs to continue to run.
>

if that was the case, the fork-into-background option would be enabled 
by default.

if you want udhcpc to act as a daemon that regularly updates the lease, 
you should start it as such and set --retries 0 so that it additionally 
keeps on running and checking forever.

it's a quite powerful tool usable in multiple different scenarios, so 
the options should do as they say instead of resulting in surprising 
behaviour.

do you agree that the -n switch (which looks like an afterthought 
anyway) is redundant with --retries 0 ?

old:
loop forever: omit -n
don't loop forever: -n -t maxtries (completely counterintuitive)

new since 1c7a58dfb82ea04c525e0c19f94f2d800dee99e3
loop forever: -t 0

and hopefully new soon:
don't loop forever: -t maxtries


More information about the busybox mailing list