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

[Phil Blundell <philb@gnu.org>]

On Tue, 2009-09-22 at 12:42 -0400, Denys Dmytriyenko wrote:
> On Tue, Sep 22, 2009 at 02:28:32PM +0100, Phil Blundell wrote:
> > On Mon, 2009-09-21 at 18:39 -0400, Denys Dmytriyenko wrote:
> > > On Mon, Sep 21, 2009 at 08:45:06PM +0100, Phil Blundell wrote:
> > > > 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.
> > 
> > True, but your original patch won't help with this situation either
> > (since "ip=dhcp" won't match the regex).  I think this is a different
> 
> Not true. The default is to start udhcpc always. I just cover one case to 
> prevent it from starting when ip=x.x.x.x

Right, but as you said in your other mail, in the case where the kernel
has already claimed a dhcp lease you want to start udhcpc with different
arguments to the usual ones.  So, although your original patch
admittedly doesn't make that situation any worse, it also doesn't make
it much better either.

I still think that this:

> > problem and probably requires a different solution: the ideal thing
> > would be for the kernel to set a flag on the interface to say that it
> > needs to be taken over by a DHCP client, or alternatively to invoke the
> > DHCP client itself via the hotplug mechanism.  Failing that you could
> > arrange for the startup scripts to poke around at /proc/cmdline and try
> > to second-guess what the kernel has done, although that would be rather
> > less satisfactory.

together with the thing I mentioned earlier, is the right way to solve
this kind of issue in general.  

Poking at /proc/cmdline from the pre-up command has another downside as
well, namely that if you bring the interface down it will then be
impossible to get it back up again because the command line will still
have the "ip=" bits in it even though they are no longer relevant.

p.