[oe] [RFC][PATCH] netbase: don't start udhcpc if kernel assigned IP statically

Denys Dmytriyenko denis at denix.org
Mon Sep 21 22:39:56 UTC 2009


On Mon, Sep 21, 2009 at 08:45:06PM +0100, Phil Blundell wrote:
> On Mon, 2009-09-21 at 12:07 -0400, Denys Dmytriyenko wrote:
> >  iface eth0 inet dhcp
> > +        pre-up /bin/grep -v -e "ip=[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+" /proc/cmdline > /dev/null
> > +
> 
> This is pretty gruesome.  It will introduce an extra two fork+exec's
> worth of overhead to every "ifup eth0" for everybody, and it also fails
> to check that the ip= parameter actually corresponded to eth0 (i.e. it
> would stop eth0 coming up even if the parameter was specifying an
> address for eth1).  

I would agree it's a quick and dirty fix, that's why it's RFC :)

As in my case we only have eth0, I didn't bother touching eth1 or any other 
interface.

Also, while the proper and complete format for the ip= parameter is:
ip=<ipaddr>:<serverip>:<gatewayip>:<netmask>:<hostname>:<iface>:<state>

Many users just specify the IP address on the command line:
ip=<ipaddr>

In this case the IP would be assigned to the first available interface, so it 
is harder to do it from the /etc/network/interfaces file using pre-up...

> It seems like there must be a better way of solving this problem.  How
> about just teaching "ifup -a" to spot interfaces that are already up and
> leave them alone?

Won't work for the case of kernel-acquired DHCP address, i.e. kernel level 
autoconfig, aka IP_PNP, aka ip=dhcp command line.

>From ifup perspective the interface is up and IP is assigned, but we need to 
start udhcpc to re-acquire and keep the lease, as kernel can't do this.

Speaking of which, I am working on a fix for udhcpc to also properly handle 
this case - it needs to be started with -r <ip> to request the same IP that 
kernel received, instead of asking for any available... Some DHCP servers are 
stupid and give a different IP, killing NFS/TCP mounted rootfs...


So, the discussion is still open - please send your comments/suggestions. 
Thanks.

-- 
Denys




More information about the Openembedded-devel mailing list