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

[Denys Dmytriyenko]

On Tue, Sep 22, 2009 at 07:00:12PM +0100, Phil Blundell wrote:
> 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.

Correct. As I was thinking on adding the check for kernel acquired DHCP lease 
somewhere inside the udhcpc code or script, it appears to be quite independent 
from this patch to pre-up...

> 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.

Fair enough, I will try to figure out a better way of fixing it for all the 
possible cases... Thanks.

-- 
Denys