Re: NetworkManager 0.8.6 doesn't reply to ActivateConnection

[Dan Williams <dcbw redhat com>]

On Mon, 2012-01-23 at 15:27 -0600, Dan Williams wrote:
> On Thu, 2012-01-19 at 19:35 +0000, David Röthlisberger wrote:
> > We are using NetworkManager 0.8.6 on a device without the official NM applet,
> > so we do all communication with NM over DBus ourselves. If there is no entry in
> > the system-connections directory *and* no "no-auto-default" entry in
> > NetworkManager.conf, then NetworkManager doesn't reply to the method call
> > org.freedesktop.NetworkManager.ActivateConnection.
> > 
> > NM *does* receive the method call and does apply the configuration, but simply
> > doesn't reply; the caller eventually gets a DBus timeout.
> > 
> > After this first call (which times out), NM has created its configuration file
> > in system-connections, and the next call works correctly.
> > 
> > I can consistently reproduce this behaviour by:
> > * killing NM, 
> > * removing any "no-auto-default" entry in NetworkManager.conf,
> > * removing everything in the system-connections directory; then
> > * starting NM
> > * and sending NM a series of method calls culminating in ActivateConnection. 
> 
> I can reproduce this with a small python program.  Clearly a bug, fixing
> it now.

The issue here is that, because it was simpler, the "default wired
connection" actually changes it's object path when it's updated.
Basically, it gets written out by the first plugin that can save
connections, and then the plugin creates a completely new connection
object for it because the plugin had no knowledge of the default wired
connection before.  Thus it gets a new object path.  Then, when you call
ActivateConnection with the old object path, NM waits around for the
connection to show up, but it never does because it's actually gone.
But it's a bug that NM doesn't time that out and return an error.  But
that would actually be unhelpful anyway.

So the real solution here is to explore how the default wired connection
can retain it's old object path when it gets reported by the settings
plugin that wrote it to disk.  Unfortunately that's not simple because
we've tried to keep the objects fairly well encapsulated from each other
internally.

Dan