GNOME Bugzilla – Bug 700300
Ethernet device automatically switches back to active when calling org.freedesktop.NetworkManager.DeactivateConnection()
Last modified: 2013-05-15 14:44:50 UTC
When you try to switch the ethernet connection off from the control center, it automatically switches back to active. Though when you do the same thing from the Gnome-Shell, it works well. Apparently the difference is that the control center uses org.freedesktop.NetworkManager.DeactivateConnection() where the Shell uses org.freedesktop.NetworkManager.Device.Disconnect(). Attached the dbus-monitor --system traces for each case.
Created attachment 244180 [details] Control center dbus-monitor traces
Created attachment 244181 [details] Shell dbus-monitor traces
Yes, DeactivateConnection() simply stops the connection and then the normal auto-activation checks happen again, which may cause the same connection to be activated again if that connection is set to autoconnect. Device.Disconnect() will do the same thing, but disable autoconnect on the device until the user manually starts a new connection or the system goes through a suspend/resume cycle. This has been documented in the NM D-Bus API docs for quite a while. Perhaps the control-center should be using Disconnect() instead?
Roger that, will patch the control center. Thanks for the quick response.
Created attachment 244229 [details] [review] network: prevent ethernet device to switch back to 'on' state Strange though, this problem doesn't happen with wifi.
Review of attachment 244229 [details] [review]: Looks good for gnome-3-8 and master.
Comment on attachment 244229 [details] [review] network: prevent ethernet device to switch back to 'on' state Committed to 3.8 and master.
(In reply to comment #3) > Yes, DeactivateConnection() simply stops the connection and then the normal > auto-activation checks happen again, which may cause the same connection to be > activated again if that connection is set to autoconnect. Some time agoi I pointed out that we should probably handle connection the same way and mark them as manually disconnected, as we do with devices. Reopening to allow discussion of this possibility. I will get back to it as right now I don't remember the specific reason that brought me to this conclusion.
This particular bug is fixed though. File a new one when it comes back to you :)
(In reply to comment #9) > This particular bug is fixed though. File a new one when it comes back to you > :) Sorry, didn't realize it was filed for the control center. Thanks for correction. Will reopen one on NetworkManager later with more information.