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 708771 - Wrong wireless icon during VPN connection
Wrong wireless icon during VPN connection
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: network-indicator
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on: 710207
Blocks:
 
 
Reported: 2013-09-25 16:55 UTC by Jan-Michael Brummer
Modified: 2014-11-18 18:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot showing the wrong network symbol (6.21 KB, image/png)
2013-09-25 16:57 UTC, Jan-Michael Brummer
Details

Description Jan-Michael Brummer 2013-09-25 16:55:32 UTC
A laptop connected to wireless indicates the correct network wireless symbol in the top bar. As soon as a VPN connection is established the wireless symbol turns into a not-connected symbol. See attached screenshot.

Expected behavior would be to show wireless connected symbol and vpn symbol.
Comment 1 Jan-Michael Brummer 2013-09-25 16:57:00 UTC
Created attachment 255707 [details]
Screenshot showing the wrong network symbol
Comment 2 Giovanni Campagna 2013-09-26 07:58:15 UTC
Thank you for your bug report.

Can you run the following commands from the looking glass, while the wrong icon is showing?

Main.panel.statusArea.aggregateMenu._network._getMainConnection()
Main.panel.statusArea.aggregateMenu._network._getMainConnection()._primaryDevice
Comment 3 Jan-Michael Brummer 2013-09-26 15:27:39 UTC
At first i checked the output when only wifi is connected:

* getMainConnection() is valid
* getMainConnection()._primaryDevice indicates object.NMDeviceWireless

After connecting to VPN the output is:

* getMainConnection() is null
* obviously the result of primaryDevice is an exception
Comment 4 Giovanni Campagna 2013-09-26 15:31:24 UTC
(In reply to comment #3) 
> After connecting to VPN the output is:
> 
> * getMainConnection() is null

Mh? So why doesn't NetworkManager report a connection in that case?
Comment 5 Jan-Michael Brummer 2013-10-01 06:27:34 UTC
So whats next? How can we solve this bug? Who is responsible?
Comment 6 Jasper St. Pierre (not reading bugmail) 2013-10-01 13:19:22 UTC
File a bug or try to debug with the NM developers.
Comment 7 Jan-Michael Brummer 2013-10-05 16:40:49 UTC
Yeah that's why i filled this one :) So you are saying that you are using the API of NM and the problem must be within NM? It's not a self-written binding to NM, correct?
Comment 8 Giovanni Campagna 2013-10-12 23:30:49 UTC
(In reply to comment #7)
> Yeah that's why i filled this one :) So you are saying that you are using the
> API of NM and the problem must be within NM? It's not a self-written binding to
> NM, correct?

Yes, we're using libnm-glib, which is provided togheter with NetworkManager.
Comment 9 wurfmaul 2013-10-17 06:44:03 UTC
I don't know if this is the right place but I wanted to add, that in my case this problem also occurs using cable connections! Everything's fine, when cable connection established, but once the vpn is connected, the "not connected"-icon appears, although everything works just fine!

* _getMainConnection(): [object instance proxy GIName:NMClient.ActiveConnection jsobj.....]
* _getMainConnection()._primaryDevice: undefined

After connection to VPN:

* _getMainConnection(): null
* _getMainConnection()._primaryDevice: <NullPointerException>
Comment 10 rasmus 2013-11-29 00:14:46 UTC
I see the same problem in 3.10.
Comment 11 Michael Catanzaro 2013-12-31 03:58:18 UTC
Jan, can you provide a link to the NetworkManager bug? Thanks.
Comment 12 zachw 2014-01-18 06:44:04 UTC
Didn't seem to be one... https://bugzilla.gnome.org/show_bug.cgi?id=722477
Comment 13 Jan-Michael Brummer 2014-11-18 18:43:19 UTC
I can no longer reproduce this behavior, therefore we can close this bug...
Comment 14 Florian Müllner 2014-11-18 18:48:53 UTC
Excellent!