[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