GNOME Bugzilla – Bug 676285
out-of-sync network status
Last modified: 2018-09-25 14:21:13 UTC
Created attachment 214286 [details] screenshot It occasionally happens that the network icon gets stuck on 'connecting'. The screenshot shows a situation where that happened to me. The icon was on 'connecting', and even successfully getting onto vpn did not make it correct itself.
Ugh! I have no idea how that can happen, the icon is updated when new active connections appear, when an activating connection becomes active and when the global NM state is updated. Did you save .xsession-errors last time it happened? Also, next time could you check nmcli and type the following in lg: Main.panel._statusArea['network']._client.state Thanks!
This deviation between NM and the GNOME Shell indicator happens to me all the time (running openSUSE 12.1 32b) it seems. Output from nmcli: #nmcli nm status RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running connected enabled enabled enabled enabled Output from lg: Main.panel._statusArea['network']._client.state r(0) = 70 Mostly the indicator gets stuck showing the "Connecting icon" but sometimes it just shows the "offline icon" when clearly connected (as I am sending this comment for example).
*** Bug 652931 has been marked as a duplicate of this bug. ***
*** Bug 647580 has been marked as a duplicate of this bug. ***
I'm not sure if this occured prior to NM 0.9.8, but I now see this occuring quite easily with the new NM in Fedora 18. Downstream description: https://bugzilla.redhat.com/show_bug.cgi?id=917317
Actually, the issue I reported downstream now isn't that it stays stuck on the "connecting" icon (which used to happen up to gnome-shell 3.4, don't recall seeing it in 3.6); rather, it now never lets go of the "connected" icon.
*** Bug 694654 has been marked as a duplicate of this bug. ***
My Bug 694654 has a few log messages that might help.
I have found a way of triggering at least one part of the bug. If I suspend my laptop while it is connected via cable, and unplug the cable while it is suspended, then on resume the connected icon is still there (and does not change), despite the menu saying "unplugged cable". If I plug the cable in again, the "connecting" icon is shown correctly, and then the "connected" icon; but if I unplug the cable again, the indicator goes back to "connected". This is from a clean boot; this time, there is absolutely nothing in logs. Giovanni, any ideas?
No specific ideas, but a similar issue happened to me on wifi, and I tracked it down to a NM bug. Reported it as 696004.
This is a potential explanation indeed. But note that in bug 662780 it was noted that restarting the Shell fixes the problem, which would indicate that NM reports a correct information if I'm not mistaken.
This is what I get here with WiFi turned off using hardware kill switch, and cable unplugged. The Shell uses a connected cable icon for the network indicator, even if the menu states that both connections are off. Restarting the Shell does not fix the bug in this case. $ gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/ActiveConnection --recurse --only-properties node /org/freedesktop/NetworkManager/ActiveConnection { node /org/freedesktop/NetworkManager/ActiveConnection/31 { interface org.freedesktop.NetworkManager.Connection.Active { properties: readonly o Master = '/'; readonly b Vpn = false; readonly b Default6 = false; readonly b Default = false; readonly u State = 0; readonly ao Devices = ['/org/freedesktop/NetworkManager/Devices/1']; readonly s Uuid = 'b92f3302-ee0f-4a7a-a9db-2e8bcbfe505e'; readonly o SpecificObject = '/org/freedesktop/NetworkManager/AccessPoint/638'; readonly o Connection = '/org/freedesktop/NetworkManager/Settings/21'; }; }; node /org/freedesktop/NetworkManager/ActiveConnection/32 { interface org.freedesktop.NetworkManager.Connection.Active { properties: readonly o Master = '/'; readonly b Vpn = false; readonly b Default6 = false; readonly b Default = false; readonly u State = 0; readonly ao Devices = ['/org/freedesktop/NetworkManager/Devices/0']; readonly s Uuid = '1a3485c7-3d34-470e-a508-0d156e46e3c6'; readonly o SpecificObject = '/'; readonly o Connection = '/org/freedesktop/NetworkManager/Settings/8'; }; }; }; $ gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/Devices --recurse --only-properties node /org/freedesktop/NetworkManager/Devices { node /org/freedesktop/NetworkManager/Devices/0 { interface org.freedesktop.NetworkManager.Device { properties: readonly ao AvailableConnections = []; readonly u DeviceType = 1; readonly b FirmwareMissing = false; readwrite b Autoconnect = true; readonly b Managed = true; readonly o Dhcp6Config = '/'; readonly o Ip6Config = '/'; readonly o Dhcp4Config = '/'; readonly o Ip4Config = '/'; readonly o ActiveConnection = '/'; readonly (uu) StateReason = (20, 40); readonly u State = 20; readonly u Ip4Address = 1315003402; readonly u Capabilities = 3; readonly s FirmwareVersion = ''; readonly s DriverVersion = '2.3LK-NAPI'; readonly s Driver = 'r8169'; readonly s IpInterface = ''; readonly s Interface = 'em1'; readonly s Udi = '/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/em1'; }; interface org.freedesktop.NetworkManager.Device.Wired { properties: readonly b Carrier = false; readonly u Speed = 1000; readonly s PermHwAddress = 'YYY'; readonly s HwAddress = 'YYY'; }; }; node /org/freedesktop/NetworkManager/Devices/1 { interface org.freedesktop.NetworkManager.Device { properties: readonly ao AvailableConnections = []; readonly u DeviceType = 2; readonly b FirmwareMissing = false; readwrite b Autoconnect = true; readonly b Managed = true; readonly o Dhcp6Config = '/'; readonly o Ip6Config = '/'; readonly o Dhcp4Config = '/'; readonly o Ip4Config = '/'; readonly o ActiveConnection = '/'; readonly (uu) StateReason = (20, 2); readonly u State = 20; readonly u Ip4Address = 167815360; readonly u Capabilities = 1; readonly s FirmwareVersion = 'N/A'; readonly s DriverVersion = '3.6.2-2.fc18.x86_64'; readonly s Driver = 'brcmsmac'; readonly s IpInterface = ''; readonly s Interface = 'wlan0'; readonly s Udi = '/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/bcma0:0/net/wlan0'; }; interface org.freedesktop.NetworkManager.Device.Wireless { properties: readonly u WirelessCapabilities = 63; readonly o ActiveAccessPoint = '/'; readonly u Bitrate = 0; readonly u Mode = 2; readonly s PermHwAddress = 'XXX'; readonly s HwAddress = 'XXX; }; }; };
Oh, and Main.panel.statusArea['network']._client.state == "20".
*** Bug 679942 has been marked as a duplicate of this bug. ***
*** Bug 697149 has been marked as a duplicate of this bug. ***
Created attachment 240962 [details] [review] [MAYBE] NetworkMenu: check that NetworkManager state is consistent NetworkManager exposes state as a global state property, as property of devices and as a property of currently active connections. We use active connections to choose the icon in the panel, but we use the device state to build the menu, and unfortunately there are bugs in NM that make them inconsistent at times. Work around them by checking also the global state and complaining if they don't match.
*** Bug 698755 has been marked as a duplicate of this bug. ***
The bug where NM wouldn't signal that an ActiveConnection was destroyed as a result of rfkill is fixed by: 22d2f571ce77f78d78a131c8df7fcbcf265b4137 though in that case, NM *is* setting the ActiveConnection's 'State' property to 0, which means "unknown", which the shell should certainly not treat as "Hey, this AC is connected!". Only the NM_ACTIVE_CONNECTION_STATE_ACTIVATED state should be treated as a connected network interface, and only NM_ACTIVE_CONNECTION_STATE_ACTIVATING should be treated as "something is connecting right now". I have verified that in NM 0.9.8.2 the State properties for ActiveConnection objects, NetworkManger itself, and NMDevice are received and re-emitted by libnm-glib. So if there are any other problems, it would be great if we can get an idea of what property is not being updated correctly so we can debug further.
I'm seeing this sporadically in git master when I connect to a VPN; nm-applet stays stuck in the connecting state, but if I kill it and restart it, it shows as connected. It doesn't happen every time though. And I've never seen it happen when connecting to wifi, only when connecting to the VPN.
This could also happen on suspend/resume, as NM wouldn't clear out the ActiveConnections property. But the referenced commit from comment 18 will fix that.
(In reply to comment #19) > I'm seeing this sporadically in git master when I connect to a VPN; nm-applet > stays stuck in the connecting state, but if I kill it and restart it, it shows > as connected. It doesn't happen every time though. And I've never seen it > happen when connecting to wifi, only when connecting to the VPN. Any chance you could #define DEBUG 1 in libnm-glib/nm-object.c and run with that until you see this the next time, so that we can figure out whether libnm-glib is getting PC signals correctly?
Again, I should also add that GNOME Shell needs to respect the "State" property of any ActiveConnection object, because not all states indicate that the connection is valid. The AC objects have five states (UNKNOWN, ACTIVATING, ACTIVATED, DEACTIVATING, DEACTIVATED) and only two of those (ACTIVATING, ACTIVATED) should be factored into the decision on what the status icon shows.
eg, this code in js/ui/status/network.js in _syncActiveConnections() is wrong: this._mainConnection = activating || default_ip4 || default_ip6 || this._activeConnections[0] || null; because it unconditionally uses the value of this._activeConnections[0], when that ActiveConnection object may not actually be in a valid state.
Created attachment 243628 [details] [review] network: don't use active connections that are in invalid states Only ACTIVE or ACTIVATING connections are important when deciding what icon to show, don't fallback on any, possibly invalid or deactivating, active connection object.
Ok, so here is the fix, right?
Review of attachment 243628 [details] [review]: It won't fix this bug (since we're seeing ACTIVATING, not UNKNOWN), but go for it.
Comment on attachment 243628 [details] [review] network: don't use active connections that are in invalid states Attachment 243628 [details] pushed as 7514607 - network: don't use active connections that are in invalid states Will push to gnome-3-8 too.
(In reply to comment #21) > Any chance you could #define DEBUG 1 in libnm-glib/nm-object.c and run with > that until you see this the next time, so that we can figure out whether > libnm-glib is getting PC signals correctly? It isn't. It gets the initial properties for the NMVPNConnection, with state=1 (ACTIVATING) and vpn-state=2 (NEED_AUTH), but it doesn't get any updates to the connection after that.
Ok(In reply to comment #29) > (In reply to comment #21) > > Any chance you could #define DEBUG 1 in libnm-glib/nm-object.c and run with > > that until you see this the next time, so that we can figure out whether > > libnm-glib is getting PC signals correctly? > > It isn't. It gets the initial properties for the NMVPNConnection, with state=1 > (ACTIVATING) and vpn-state=2 (NEED_AUTH), but it doesn't get any updates to the > connection after that. Ok, next can you enable the debugging stuff in src/nm-properties-changed-helper.c and see if the VPN state signals get emitted on the NM side?
So we most likely do have some issues with VPN vs. ActiveConnection properties-changed signal emission. NMVPNConnection doesn't register for its own PC signals, but the parent ActiveConnection does register, and that will actually handle all the properties. While I don't know without digging what D-Bus Interface the PC signal will actually go out on, I suspect that the VPNConnection properties are actually going out on the ActiveConnection D-Bus interface. The libnm-glib code actually cares about the D-Bus interface of the PC signal, so the libnm-glib NMVPNConnection object will actually ignore any of the PC signals for VPN properties (VpnState, Banner, etc) because they're getting emitted on the ActiveConnection D-Bus interface.
*** Bug 699268 has been marked as a duplicate of this bug. ***
The committed patch broke showing the secondary icon when connected to a VPN.
*** Bug 701027 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > I'm seeing this sporadically in git master when I connect to a VPN oops, this turned out to be a new bug in git master, so not the same as the original (which is apparently fixed by Giovanni's gnome-shell patch anyway). So moving the bug back to gnome-shell.
Created attachment 246978 [details] dbuslog from 3.9.1 on opensuse Reproduced the behaviour and desrt annotated the log.
*** Bug 703357 has been marked as a duplicate of this bug. ***
*** Bug 696004 has been marked as a duplicate of this bug. ***
(In reply to comment #36) > Created an attachment (id=246978) [details] > dbuslog from 3.9.1 on opensuse > > Reproduced the behaviour and desrt annotated the log. Do you happen to know what version of NetworkManager you were running at that time?
I'm still seeing this bug with gnome-shell 3.8.4-2 and NetworkManager 0.9.8.2-8.git20130709 on Fedora 19. For example, I'm currently connected to the WiFi, and still the indicator shows the three "connecting" dots. gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager/ActiveConnection --recurse --only-properties node /org/freedesktop/NetworkManager/ActiveConnection { node /org/freedesktop/NetworkManager/ActiveConnection/100 { interface org.freedesktop.NetworkManager.Connection.Active { properties: readonly o Master = '/'; readonly b Vpn = false; readonly b Default6 = false; readonly b Default = true; readonly u State = 2; readonly ao Devices = ['/org/freedesktop/NetworkManager/Devices/1']; readonly s Uuid = 'b92f3302-ee0f-4a7a-a9db-2e8bcbfe505e'; readonly o SpecificObject = '/org/freedesktop/NetworkManager/AccessPoint/22503'; readonly o Connection = '/org/freedesktop/NetworkManager/Settings/25'; }; }; };
The network code has changed significantly in the last five years, so any bugs discussed here are very unlikely to be relevant for bugs in the current code.