From: Denys Dmytriyenko <denis@denix.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC][PATCH] netbase: don't start udhcpc if kernel assigned IP statically
Date: Mon, 21 Sep 2009 18:39:56 -0400 [thread overview]
Message-ID: <20090921223956.GF3599@denix.org> (raw)
In-Reply-To: <1253562306.16477.38.camel@lenovo.internal.reciva.com>
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
next prev parent reply other threads:[~2009-09-21 22:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-21 16:07 [RFC][PATCH] netbase: don't start udhcpc if kernel assigned IP statically Denys Dmytriyenko
2009-09-21 19:45 ` Phil Blundell
2009-09-21 22:39 ` Denys Dmytriyenko [this message]
2009-09-22 8:54 ` Stanislav Brabec
2009-09-22 13:28 ` Phil Blundell
2009-09-22 16:42 ` Denys Dmytriyenko
2009-09-22 18:00 ` Phil Blundell
2009-09-22 18:32 ` Denys Dmytriyenko
2009-09-21 20:46 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090921223956.GF3599@denix.org \
--to=denis@denix.org \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox