After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698962 - VPN network indicator gets stuck on 'Off' states
VPN network indicator gets stuck on 'Off' states
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: network-indicator
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 698963 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-04-26 15:27 UTC by Lionel Landwerlin
Modified: 2021-07-05 14:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
network: use custom checkConnection() for VPN connections (2.06 KB, patch)
2013-04-26 15:27 UTC, Lionel Landwerlin
needs-work Details | Review
network: use custom checkConnection()/removeConnection() for VPN connections (2.72 KB, patch)
2013-04-29 00:30 UTC, Lionel Landwerlin
none Details | Review

Description Lionel Landwerlin 2013-04-26 15:27:02 UTC
The problem here is that the code checkConnection() method in NMConnectionBased is using the timestamp associated to a connection to established whether a connection should be remove and added straight in the code path. The purpose of the remove&add being to sort the connections by order of last change. On the VPN connection, any change of state will remove the item from the menu and readd it straight away. Until the setActiveConnection() method is called on the NMVPNSection the state of the connection is display as 'Off' and because the connection hasn't change its active state, setActiveConnection() is never called after the remove&add from checkConnection().
Comment 1 Lionel Landwerlin 2013-04-26 15:27:51 UTC
Created attachment 242585 [details] [review]
network: use custom checkConnection() for VPN connections
Comment 2 Giovanni Campagna 2013-04-26 16:06:14 UTC
Review of attachment 242585 [details] [review]:

The issue is, we need a custom removeConnection too, so we can clear the signal on the .active object when it's dropped.
At which point, there is not much code sharing happening, so we can get rid of NMConnectionBased, fold it into NMDevice, and have the custom thing for VPN.
Comment 3 Jasper St. Pierre (not reading bugmail) 2013-04-26 22:58:53 UTC
Review of attachment 242585 [details] [review]:

::: js/ui/status/network.js
@@ +1561,3 @@
+        let valid = this.connectionValid(connection);
+
+        if (exists && valid) {

connectionValid always returns true, so we'll never reach removeConnection anyway.
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-04-26 23:18:47 UTC
Review of attachment 242585 [details] [review]:

::: js/ui/status/network.js
@@ +1564,3 @@
+            // Update active connection
+            let obj = this._connections[pos];
+            obj.active = connection;

I think this is also wrong as well; connection here is a NMConnection, not an NMActiveConnection, which is what obj.active wants.
Comment 5 Lionel Landwerlin 2013-04-28 12:04:16 UTC
I would like to see that fixed for 3.8. And this isn't gonna fly if I start refactoring code. So do we agree on a custom removeConnection() for VPN + fixes following Jasper's review?
Comment 6 Lionel Landwerlin 2013-04-28 12:05:07 UTC
Since 3.10 is going to be a rewrite of this code because the design changes.
Comment 7 Lionel Landwerlin 2013-04-29 00:30:09 UTC
Created attachment 242763 [details] [review]
network: use custom checkConnection()/removeConnection() for VPN connections
Comment 8 Lionel Landwerlin 2013-05-28 09:29:17 UTC
Ping?
Comment 9 Lionel Landwerlin 2013-06-10 11:03:45 UTC
Just upgraded to 3.8.3, this problem is still present...
Comment 10 Dan Williams 2013-09-20 20:21:13 UTC
Just ran into this too; note that 3.10 shell has rewritten checkConnection and it no longer looks at the timestamp at all.  I'm not sure why it *ever* looked at the timestamp, the UUID is the only thing that should be used to uniquely identify a connection, and this is what 3.10 uses.

So I don't think the patches need to copy checkConnection; the right fix for 3.8 would be simply to compare the UUID in checkConnection instead of the (name+timestamp).
Comment 11 Dan Williams 2013-09-20 20:22:27 UTC
*** Bug 698963 has been marked as a duplicate of this bug. ***
Comment 12 Dan Williams 2013-09-20 20:28:07 UTC
Basically, does this patch fix things for anyone?

    checkConnection: function(connection) {
        let pos = this._findConnection(connection.get_uuid());
        let exists = pos != -1;
        let valid = this.connectionValid(connection);
        let same = false;
        if (exists) {
            let existing = this._connections[pos];

-            // Check if connection changed name or id
-            similar = existing.name == connection.get_id();
-                existing.timestamp == connection._timestamp;
+            same = existing.uuid == connection.get_uuid();
        }
Comment 13 Dan Williams 2013-09-20 20:31:20 UTC
    checkConnection: function(connection) {
        let pos = this._findConnection(connection.get_uuid());
        let exists = pos != -1;
        let valid = this.connectionValid(connection);
        let similar = false;
        if (exists) {
            let existing = this._connections[pos];

-            // Check if connection changed name or id
-            similar = existing.name == connection.get_id();
-                existing.timestamp == connection._timestamp;
+            similar = existing.uuid == connection.get_uuid();
        }

Fixed the patch...
Comment 14 Alessio Gaeta 2013-11-11 13:55:08 UTC
Hello,
the patch in comment #13 seems to work for me. After applying it the switch seems to behave as expected.
--
Alessio Gaeta
Comment 15 Alessio Gaeta 2014-04-14 20:47:25 UTC
Any news on this?
Comment 16 GNOME Infrastructure Team 2021-07-05 14:32:51 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.