udhcpc causes system rebooting

[Piotr Piwko]

2010/2/4 Denys Vlasenko <vda.linux at googlemail.com>:
> Run  udhcpc -f -vvv -i eth0 -s /bin/udhcpc.script
> so that it doesn't daemonize and talks much more.
> What does it say?

Nothing else then:

[root at netradio /]# udhcpc -f -vvv -i eth0 -s /bin/udhcpc.script
version 1.13.3

but the udhcpc -f -i eth0 -s /bin/udhcpc.script returns:

[root at netradio /]# udhcpc -f -i eth0 -s /bin/udhcpc.script
udhcpc (v1.13.3) started
Sending discover...
Sending select for 192.168.2.101...
Lease of 192.168.2.101 obtained, lease time 140773632
adding dns 192.168.2.1

> Post your /bin/udhcpc.script

--------------------------[begin of udhcpc.script]--------------------------
#!/bin/sh

# udhcpc script edited by Tim Riker <Tim at Rikers.org>

[ -z "$1" ] && echo "Error: should be called from udhcpc" && exit 1

RESOLV_CONF="/etc/resolv.conf"
[ -n "$broadcast" ] && BROADCAST="broadcast $broadcast"
[ -n "$subnet" ] && NETMASK="netmask $subnet"

case "$1" in
       deconfig)
               /sbin/ifconfig $interface 0.0.0.0
               ;;

       renew|bound)
               /sbin/ifconfig $interface $ip $BROADCAST $NETMASK

               if [ -n "$router" ] ; then
                       while route del default gw 0.0.0.0 dev $interface 2>/deo
                               :
                       done

                       metric=0
                       for i in $router ; do
                               route add default gw $i dev $interface metric $)
                       done
               fi

               echo -n > $RESOLV_CONF
               [ -n "$domain" ] && echo search $domain >> $RESOLV_CONF
               for i in $dns ; do
                       echo adding dns $i
                       echo nameserver $i >> $RESOLV_CONF
               done
               ;;
esac

exit 0
--------------------------[end of udhcpc.script]--------------------------

>> I use BusyBox v1.13.3 with Linux 2.6.29.4 kernel.
> Try newer version, say, 1.15.3

I've just finished testing, unfortunately without any successful
result ... There is the same problem.

-- 
Piotr Piwko
http://www.embedded-engineering.pl/