Openembedded Devel Discussions
 help / color / mirror / Atom feed
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



  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