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 _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
