[BusyBox] Question on udhcpc?

Mon Mar 10 11:18:03 UTC 2003

Russ Dill wrote:
>> Don't know, some more info would be helpful, like what script, some
>> output, etc

Here's the output I get from running it in the script. Debugging is turned
on. The only difference between this output and running it from the command
line is that running it from the command line obtains a lease. Note that the
script is /etc/init.d/rcS, and the shell is /bin/sh. Udhcpc resides where
busybox --install puts it (/sbin, if memory serves). Udhcpd isn't configured
into busybox, and the only shell I have configured in is ash. The
/usr/share/udhcpc/default.script is essentially the simple.script given in
the examples directory, modified to echo the variable information
(interface, ip, broadcast, etc) into /etc/network.conf so that other scripts
can read the information easily.

The "/dev/urandom: No such file or directory" is due to the fact that I'm
being supplied the kernel by another group that I have no influence over. :(
Doesn't seem to effect udhcpc when run from the command line, though.

Starting pid 8, console /dev/ttyS0: '/etc/init.d/rcS'
info, udhcp client (v0.9.9-pre) started
info, adapter index 2
info, adapter hardware address 00:d0:b7:57:eb:e8
info, execle'ing /usr/share/udhcpc/default.script
info, entering raw listen mode
info, Opening raw socket on ifindex 2

warning, Could not load seed from /dev/urandom: No such file or directory
info, adding option 0x35
info, adding option 0x3d
info, adding option 0x3c
debug, Sending discover...
info, Waiting on select...

info, adding option 0x35
info, adding option 0x3d
info, adding option 0x3c
debug, Sending discover...
info, Waiting on select...

info, No lease, failin
Please press Enter to activate this console.

Jonas Holmberg wrote:
> I think the problem is that you don't have a link to your hub or switch
> at the time you start udhcpc. udhcpc will retry (at least the version not
> in busybox) but if the link still isn't up unitl a couple of retries have
> been made I guess that there's a back-off algorithm that makes it sleep
> for quite a while before making the next try. Try waiting a couple of
> minutes... I don't know if there's a nice workaround for this problem.
> I don't think so. The not-so-nice workaround is to sleep a little after
> configuring the network device to give time for the ethernet tranceiver
> to negotiate with the hub/switch/whatever on the other side.

Thanks for the suggestion. However, I tried delaying it by putting a sleep
for 5 seconds and placing it in later scripts with no luck. Though placing
dhcpc in the background isn't really an option for me in this application (I
need to know if a lease is obtained. If not I need to fall back to some
proprietary protocols I wrote a while ago), I did try it. Still never
obtained a lease.

A man who carries a cat by the tail learns something he can learn in no
other way.
-- Mark Twain