Re: dispatcher bug

[Dan Williams <dcbw redhat com>]

On Sun, 2010-03-21 at 01:28 +0100, ich wrote:
> On Sunday, 21.03.2010 00:56:22 ich wrote:
> > Hello,
> > 
> > I have a local PPPoE connection with a dispatcher script. However it is
> > called inconsistently. Upon activating the connection, scripts are called
> > correctly with the parameters "ppp0 up". However when disconnecting, the
> > dispatcher script is called with the parameters "eth0 down". It has been
> > like that for quite some time now, but only recently has it started to
> > annoy me enough to investigate.
> > 
> > Is that worth a bug report?
> 
> Hm, I just realized NM actually "takes down" eth0 when I take down ppp0. What 
> the dispatcher script does is start "dhcpcd -t 5 eth0", which gives an IPv4LL 
> address to eth0. Now I don't see how NM comes to think it has the authority to 
> just remove that address from eth0 when I disconnect my PPPoE connection. I've 
> seen that kind of behaviour in other situations, too, when NM just changes 
> network settings that no one has told it to fiddle with.

At the moment, PPPoE support in NM is insufficiently modular.  It's
currently tied to the underlying device, so when you terminate the PPPoE
connection, that also takes down the eth0 device.  There's been a plan
in place for a while to decouple the two, which I think is what you're
looking for.  That's not done yet, but there is an open enhancement
request for it.

That's the real fix: don't have the tight coupling between the
underlying device and the PPPoE bits.

> So I guess this is not an actual bug but rather a political question:
> Should NM consider itself the one and only authority for managing network 
> settings or should it try to interfere as little as possible with pre-existing 
> settings?

It's always pretty much been the one single authority for the interfaces
that you tell it to manage.  It's not really possible to do everything
that needs to be done if NM doesn't have all the information about the
interfaces that need to be managed.

But that's not really your problem; your problem is what I described
above.  At the moment, to NM, there isn't a difference between eth0 and
ppp0; it looks just the same to NM as say ttyUSB0 and ppp0 do for a
PPP-based 3G connection.  The underlying device (eth0 or ttyUSB0) isn't
being used by NM for anything other than the PPP bits, so it gets taken
down too.

Dan