When connecting to a wireless network, the applet continues to show the spinning wheel even after the network connection is made. The spinning appears on top of both the system tray icon, and in the network list (to the right of the network name) if I open the applet. When hovering over the connected network (that has the spinning wheel), the "Disconnect" button correctly appears, while all the others reveal the "Connect" button. So the applet knows that the right network is connected, I think; it just continues to show the spinning circle. Reproducible: Always Steps to Reproduce: 1. Turn off wifi from nm-applet 2. Turn wifi back on, wait for reconnect to remembered network 3. Notice that wheel is still spinning Actual Results: Wheel spins even after connection Expected Results: Wheel should disappear because network is connected I believe this might have appeared after I attempted to connect to an openconnect vpn (I don't remember it before), but I cannot confirm.
Could you please send output from the command below once this happen again? for x in `qdbus --system --literal org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.ActiveConnections | grep -io "/org/freedesktop/NetworkManager/ActiveConnection/."`; do qdbus --system --literal org.freedesktop.NetworkManager $x org.freedesktop.NetworkManager.Connection.Active.Id; qdbus --system --literal org.freedesktop.NetworkManager $x org.freedesktop.NetworkManager.Connection.Active.State; echo "-------"; done
Sure thing, here it is: [Variant(QString): "vpn0"] [Variant(uint): 2] ------- [Variant(QString): "UMD"] [Variant(uint): 2] ------- [Variant(QString): "MYSSID-5GHz"] [Variant(uint): 2] ------- I rebooted this morning, and this problem actually didn't occur until I connected to my work VPN (named "UMD"). It is an openconnect connection. In fact, at this moment the wireless connection does not have the spinning circle, but the VPN does, even though I have been stably connected for over 3 hours now.
Ah, so the spinning circle is not over the systray icon, but in the applet, right? Could you run again the command below? for x in `qdbus --system --literal org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.ActiveConnections | grep -io "/org/freedesktop/NetworkManager/ActiveConnection/."`; do qdbus --system --literal org.freedesktop.NetworkManager $x org.freedesktop.NetworkManager.Connection.Active.Vpn | grep "true" > /dev/null; if [ $? -eq 0 ]; then qdbus --system --literal org.freedesktop.NetworkManager $x org.freedesktop.NetworkManager.VPN.Connection.VpnState; fi; done Sorry for such complicated command, it's night and I'm lazy to come up with a shorter command :)
Created attachment 94480 [details] Spinning wheel in applet
Created attachment 94481 [details] Spinning wheel in tray
My apologies, the spinning actually shows up both in the tray and in the applet. Please see the attached screenshots for an example. The output of that command was: [Variant(uint): 5]
I see, one more thing to try. Could you please disconnect your VPN connection and run again the command below,keep it running and then activate your VPN connection and once it get's activated (at least you think it's activated or you verify that) you can kill it and attach here the output? Command: dbus-monitor --system "type='signal',sender='org.freedesktop.NetworkManager'"
Created attachment 94482 [details] Output of NetworkManager dbus monitor during VPN connection Sure thing, it's attached here. I disconnected my VPN, started the monitor, connected to the VPN, verified I could access an sshfs mount on the remote, and then disconnected the VPN, and shut down the monitor. While I can access the VPN connection with no problem, it says "Needs authorization" in the applet next to the spinning wheel. Seems as though the vpn isn't communicating that it actually connected?
What version of NetworkManager do you have? I see a bug there, it doesn't send VpnStateChanged signal once your VPN connection gets activated. NM only sends VpnStateChanged signal when you disconnect your VPN connection or when you start activating it.
Ok, forget about the comment above, NM actually sends that signal and I didn't see it.
For what it's worth, I'm using the following from the Arch repos: networkmanager-openconnect 1.0.2-2 networkmanager 1.0.6-1
Now it starts looking as a bug in plasma-nm, hopefully last thing to check. Deactivate your VPN connection and run following commands: export QT_LOGGING_RULES=plasma-nm*.debug=true killall plasmashell plasmashell & Then activate your VPN connection and again paste the output here please.
Created attachment 94483 [details] Output of plasmashell So, oddly enough, restarting plasmashell seemed to fix it. I've uploaded the log, but now there is no spinning, even after I connect to the VPN...
Weird, I also see in the log that everything is correct and your UMD VPN connection state was changed to 2 which means that it was activated and that's why you don't see the spinning circle.
Well now I can't explain it. I rebooted this morning, and it appears that all is well. Even though the problem showed up after a fresh reboot yesterday. Is there some environment variable I can set so that plasma always creates a debug log? That way if I notice it happening, I can have the output to post here?
Same issue here, without any vpn, just a simple wifi connection. This always happens after my ISP drops the connection, then I click "disconnect" and immediately "connect" on the popup applet. After that, it connects to the network but the icon keeps spinning and the only way to fix it is to restart plasmashell. Using Plasma 5.4.1. Output of command #2: [Variant(QString): "YOQUESE"] [Variant(uint): 2] -------
Sorry for late response. You can put "export QT_LOGGING_RULES=plasma-nm*.debug=true" into your .bashrc file and then plasma-nm logs should be available in .xsession-errors.
This happens to me as well using plasma-nm from master. You can usually poke me on #kde-devel on Freenode if you need help debugging this. Its not always reproducable, though.
This happens to me as well with Plasma 5.4.1 and NetworkManager 1.0.6. No VPN, just regular WiFi.
I don't think that any recent change in plasma-nm broke this, my assumption is that something changed in NetworkManager recently. Is everyone running NetworkManager 1.0.6?
@Emil Sedgh, @Ragnar Thomsen could you please guys provide the output from the command in comment 7?
I'm not able to reproduce the issue ATM. It happened when I reconnected after being disconnected from a bad wifi router. I will supply the dbus output if it happens again...
I copied the output here: https://paste.kde.org/ps1wfwocy Please note the dbus-monitor while running for quite some time until this happened, hence the long output. I am using NM from Debian packages version 1.0.6-1 One important note is that plasma-nm shows 'Connected' as the state of connection. Im attaching a screenshot.
Created attachment 94683 [details] Plasma-nm with 'Connected' state
Here is the output of my plasmashell when this happened: https://paste.kde.org/phs2wri23 Sorry its too long, I had to run plasmashell and wait for it to reproduce.
One thing I noticed is that plasma-nm works fine up to some point. But it gets confused at some point and from then, all the connections you make, stay in 'Connecting' state. A restart to the plasmashell fixes the problem, until some time later that it happens again. What I'm trying to say is that the problem seems to depend on some global state of plasma-nm and its not a per-connection issue.
I wonder if this bug is archlinux-specific? I have not been able to reproduce it on demand, but after a day or so it's almost guaranteed to happen while on a VPN. Also, for me, plasmashell uses quite a bit of CPU whilst showing the spinner. That is probably a separate bug, but it makes this bug more than a minor annoyance.
As requested on IRC, here are another set of logs: dbus-monitor: https://paste.kde.org/pvhqv2foo plasmashell: https://paste.kde.org/ppdsxnpr9 The output is from the moment I clicked on 'Connect' button.
Created attachment 94901 [details] Notification Jan, you also said that the 'Connected' state shown on the applet is about the network interface, not the connection. This attachment might be interesting to you.
plasmashell with latest debug information: https://paste.kde.org/ppd7nghfu
Please note that I noticed it mostly happens after resuming from suspend (to ram).
One more set of debug output, this time including nm-qt: plasma-nm: New wireless network "UPC1739970" added plasma-nm: New wireless network "UPC5719832" added plasma-nm: New wireless network "UPC2356837" added plasma-nm: New wireless network "UPC7224343" added plasma-nm: Item "TP-LINK_M5350_ADF44E" : active connection state changed to 1 plasma-nm: NetworkManager state changed to 3 plasma-nm: NetworkManager state changed to 2 plasma-nm: Item "dd-wrt" : active connection removed plasma-nm: NetworkManager state changed to 4 plasma-nm: Item "TP-LINK_M5350_ADF44E" : connection updated plasma-nm: NetworkManager state changed to 7 networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Metered" plasma-nm: Item "TP-LINK_M5350_ADF44E" : connection updated
One more debug output: networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) QMap(("ActiveConnections", QVariant(QDBusArgument, ))) networkmanager-qt: "/org/freedesktop/NetworkManager/ActiveConnection/32" networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) QMap(("ActivatingConnection", QVariant(QDBusObjectPath, ))("ActiveConnections", QVariant(QDBusArgument, ))("State", QVariant(uint, 40))) networkmanager-qt: "/org/freedesktop/NetworkManager/ActiveConnection/32" networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) QMap(("ActiveConnections", QVariant(QDBusArgument, ))) networkmanager-qt: "/org/freedesktop/NetworkManager/ActiveConnection/32" networkmanager-qt: void NetworkManager::NetworkManagerPrivate::propertiesChanged(const QVariantMap&) QMap(("ActivatingConnection", QVariant(QDBusObjectPath, ))("Connectivity", QVariant(uint, 4))("Metered", QVariant(uint, 4))("PrimaryConnection", QVariant(QDBusObjectPath, ))("PrimaryConnectionType", QVariant(QString, "802-11-wireless"))("State", QVariant(uint, 70))) networkmanager-qt: virtual void NetworkManager::DevicePrivate::propertyChanged(const QString&, const QVariant&) Unhandled property "Metered"
When it works properly, I also get these in my console: networkmanager-qt: void NetworkManager::ActiveConnectionPrivate::propertiesChanged(const QVariantMap&) QMap(("Default", QVariant(bool, true))("Dhcp4Config", QVariant(QDBusObjectPath, ))("Dhcp6Config", QVariant(QDBusObjectPath, ))("Ip4Config", QVariant(QDBusObjectPath, ))("Ip6Config", QVariant(QDBusObjectPath, ))("State", QVariant(uint, 2))) networkmanager-qt: void NetworkManager::ActiveConnectionPrivate::propertiesChanged(const QVariantMap&) Active connection "/org/freedesktop/NetworkManager/ActiveConnection/33" state changed to 2 But when the bug happens, I don't get them.
I'm seeing this exact problem since upgrading to kubuntu Wily on plain wireless connection after reconnect, seems to be related to reconnect after suspend like said before. "killall plasmashell; plasmashell &" fixes the glitch. network-manager in wily is 1.0.4-0ubuntu5 plasma-nm is 4:5.4.2-0ubuntu1
Created attachment 95419 [details] Proposed fix/workaround for this issue Can someone test this patch? I managed to finally reproduce this issue and this fix seems to help to avoid the problem.
Forgot to mention that the patch is for networkmanager-qt and not for plasma-nm.
Git commit 3a9dadfc8929cb2977f904158a5854836413fc41 by Jan Grulich. Committed on 11/11/2015 at 14:06. Pushed by grulich into branch 'master'. Re-check connection state and other properties to be sure they are actual REVIEW:126029 M +66 -0 src/activeconnection.cpp http://commits.kde.org/networkmanager-qt/3a9dadfc8929cb2977f904158a5854836413fc41
This bug is pretty important for laptop users (or those with limited cpu resources) given bug 311799 (https://bugs.kde.org/show_bug.cgi?id=311799).
*** Bug 357099 has been marked as a duplicate of this bug. ***
Reopening, doesn't seem to be solved, see Bug 357099.
Created attachment 96441 [details] Proposed fix/workaround for this issue Is anyone able to test this patch for networkmanager-qt?
I pushed the proposed patch to Fedora packages so anyone using Fedora should be able to test it in kf5-networkmanager-qt-5.18.0-2 package. It should land in updates-testing soon.
Git commit 402c1f27fc37ba93069b8c2fa6b0ee6f3c9d198f by Jan Grulich. Committed on 11/01/2016 at 11:21. Pushed by grulich into branch 'master'. Re-check connection state and other properties to be sure they are actual (version 2) REVIEW:126715 M +73 -60 src/activeconnection.cpp M +6 -0 src/activeconnection_p.h http://commits.kde.org/networkmanager-qt/402c1f27fc37ba93069b8c2fa6b0ee6f3c9d198f
*** Bug 359746 has been marked as a duplicate of this bug. ***
Just wanted to add my vote to resolve this bug. - This bug is not Arch Linux only related. I am on OpenSUSE Tumbleweed. - NetworkManager 1.0.10-1.2 - plasma-nm5 5.5.4-1.1 - For me this also happens with connection to an OpenVPN server. The WiFi state is shown as connected, while the VPN is shown as connecting, when in fact it is already connected via the OpenVPN server. All three state icons (the two for WiFi and OpenVPN in the applet menu, and the tray icon) are spinning. - This does not happen after reboot, but does often (not always) happen after a suspend. - As with others, restarting plasmashell shows all icons connected, no spinning. For what it's worth, hopefully it helps.
I'm still not able to reproduce this problem (with wifi or with openvpn/vpnc). I'm afraid that until there is a clear reproducer I won't be able to fix this.
For the record; since upgrading Fedora 22 from KDE 5.4.3 to 5.5.4 and/or stopping to use a GSM modem so often, the bug never happened to me again (it was succeeded by outright crashes after connecting). What are the debug information that you would like to see in case it happens again? How to collect it?
(In reply to Jan Grulich from comment #48) > I'm still not able to reproduce this problem (with wifi or with > openvpn/vpnc). I'm afraid that until there is a clear reproducer I won't be > able to fix this. The "problem" is that I do not have this issue anymore. After an update of OpenSUSE I saw the following (related and seemingly unrelated) changes: - plasma-nm5 seems to be the same version as before, 5.5.4-1.1 - NetworkManager also seems to be the same version, 1.0.10-1.2 - The wi-fi icon now has a small lock when connected via VPN, so at least something related has changed - Unfortunately, I do not know what else was updated Same question as above, if this happens again, what should I do to collect useful information?
I think I found a reliable reproducer on my F23 with current code base: install the weather applet from for the yr.no weather data. Then enable it in your task bar. After that, the nm-applet starts spinning. When I remove the applet and restart plasma (I log out and log in again), the nm-applet does not spin. Only after re-enabling the weather applet, the spinning behavior starts again.
(In reply to Stephan Mueller from comment #51) I also did have this weather applet enabled when I had the bug and still have it now when I do not have it anymore after an update that resolved the bug. And, if this is relevant, before the update after installing the weather applet, for some reason, it was shown up twice in the Add Widgets panel. So, if I click Add Widgets, and type "weather" in the search box, it would show me the applet twice with all options in sync, i.e. if I add one, the other is shown added as well, if I remove one, the other is shown removed as well etc. I tried to reinstall the applet several times with reboots, same result. After the update everything is OK, and there is only one applet shown in Add Widget dialog. So, given your message, now I do not know if this is relevant.
I don't think that the weather applet is related to this issue. I thought it got fixed with kf5-networkmanager-qt-5.19, but already got a report that this issue is reproducible even with the fix I was hoping that solves this issue. You can provide information mentioned in [1]. I need both logs before you reproduce this issue and during the time you manage to reproduce it. I can give it another try, but unfortunately previous logs were not helpful :(. [1] - https://techbase.kde.org/Projects/Solid/Plasma-nm#My_connection_in_the_applet_shows_wrong_information
(In reply to Jan Grulich from comment #53) > [1] - https://techbase.kde.org/Projects/Solid/Plasma-nm#My_connection_in_the_applet_shows_wrong_information This is a very useful link. Hopefully, I won't be able to reproduce the issue again, but if I do, I'll try to use that info to create logs.
(In reply to Jan Grulich from comment #53) I am actually facing this issue again. So, even after update it is still present at times, though less often. Here is another clue. I was connected via VPN on one wireless network. Then I suspended my laptop, and came to another place with a different wireless network. And once my computer woke up, it keeps spinning on the other wireless network, showing as before that it is connected to the wireless, but connecting to VPN, though the Internet is up, and my ip shows that I am connected. So, could you please try a similar setup yourself? That is connect to some VPN on one wireless network, suspend, and resume on another one? Unfortunately, I am not able to see the debug commands you referenced at the moment (even though yesterday I could), as right now that page instead of commands shows "Invalid tag extension name: syntaxhighlight".
Here on opensuse with libKF5NetworkManagerQt6-5.19.0, plasma-nm5-5.5.5 and NetworkManager-1.0.6 i was still having the issue. But after seeing you mention the yr.no weather applet, i removed mine. I was using it too since a few months. After removing the weather applet and rebooted the laptop, i didn't had the issue anymore. I connected to multiple different VPN technoly (pptp, openvpn & openconnect), the laptop also went on suspend and resumed many times, with no problem. I also see that another problem i had (removable devices notification applet was not reflecting the mount status) is also gone. And it also feels that the whole plasma interface is now smoother, but that may be only in my head. So there is definitely an issue with the weather applet that cause multiple plasma issues, including this one.
I have this issue intermittently. The actual wireless connection is solid (tried at home and at a retail establishment). - About half the time, icon in system tray for "Network Connections" applet shows the wifi icon with spinning circle around it. The popup reports "WiFi: Connected to <ESSID>". On clicking on the icon, applet window shows status "Connected". - Occasionally, same as above, except the popup shows "Connecting". - About half the time, it behaves as expected. Description: Fedora release 23 (Twenty Three) installed package plasma-nm-5.6.4-1.fc23.x86_64
*** Bug 366383 has been marked as a duplicate of this bug. ***
Also happening to me on gentoo stable, running Networkmanager 1.0.12 plasma 5.6.5
(In reply to Stephan Mueller from comment #51) Removing the weather applet fixed for me as well.
*** Bug 370857 has been marked as a duplicate of this bug. ***
My problem was gone after systemd was updated. Not sure if it is gone totally or may come back some day.
This is happening for me now too on KDE Neon 5.8. Both in the tray icon and in the applet itself.
The problem come back to me. It happened mostly in such a situation: I boot or resume my computer and it automatically connect to school WiFi (support IPv6, no password). Restarting plasmashell solves the problem. After that, disconnect and reconnect WiFi won't cause problem anymore. Even resume doesn't affect. But restart system bring the problem back. But haven't found any way to address the issue.
(In reply to Nicholas Estrada from comment #63) > This is happening for me now too on KDE Neon 5.8. Both in the tray icon and > in the applet itself. Hi Nicholas! Can you provide following information: 1. your networkmanager package version 2. your networkmanager-qt package version 3. are you using the weather widget? Thanks!
Package: network-manager Status: install ok installed Architecture: amd64 Version: 1.2.2-0ubuntu0.16.04.3 I couldn't find any package called networkmanager-qt. I am not using any weather widget. Thank you :)
(In reply to Nicholas Estrada from comment #66) > Package: network-manager > Status: install ok installed > Architecture: amd64 > Version: 1.2.2-0ubuntu0.16.04.3 > > I couldn't find any package called networkmanager-qt. > > I am not using any weather widget. > > Thank you :) It should be libkf5networkmanagerqt6 in ubuntu based distributions.
(In reply to Guo Yunhe (郭云鹤) from comment #67) > (In reply to Nicholas Estrada from comment #66) > > Package: network-manager > > Status: install ok installed > > Architecture: amd64 > > Version: 1.2.2-0ubuntu0.16.04.3 > > > > I couldn't find any package called networkmanager-qt. > > > > I am not using any weather widget. > > > > Thank you :) > > It should be libkf5networkmanagerqt6 in ubuntu based distributions. Package: libkf5networkmanagerqt6 Status: install ok installed Priority: optional Section: libs Installed-Size: 1289 Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Architecture: amd64 Source: networkmanager-qt Version: 5.27.0-0neon+16.04+build11
Same here on openSUSE 42.2 using a Thinkpad T460 and a Thinkpad T400 Laptop. If you want me to provide further info, I could provide, as this is a really annoying issue.
(In reply to christian.herenz from comment #69) > Same here on openSUSE 42.2 using a Thinkpad T460 and a Thinkpad T400 Laptop. > > If you want me to provide further info, I could provide, as this is a really > annoying issue. Can you post a screenshot of your desktop? (including panel, desktop widget, tray icons, hidden system tray icons in the popup menu) I found this problem is caused by Weather widget on openSUSE 42.1. If you remove Weather widget, the problem might disappear. However, on different hardware and system, the result is different.
(In reply to Guo Yunhe (郭云鹤) from comment #70) > I found this problem is caused by Weather widget on openSUSE 42.1. If you > remove Weather widget, the problem might disappear. OK, I disabled the weather widget now and indeed the problem has disappeared for me. Do we need to file a bug against the weather widget then?
(In reply to christian.herenz from comment #71) > OK, I disabled the weather widget now and indeed the problem has disappeared > for me. Do we need to file a bug against the weather widget then? Good to know. Though it is very likely related to weather widget, I am not sure if we should submit this bug to weather widget. Here are some users have the spinning problem without weather widget. Maybe some other widgets also cause the spinning bug. Could any developers reproduce this bug with a weather widget? If people can reproduce this bug, then it is easier to fix.
(In reply to Guo Yunhe (郭云鹤) from comment #70) > [...] > I found this problem is caused by Weather widget on openSUSE 42.1. If you > remove Weather widget, the problem might disappear. Same for me. Used to have the problem in openSUSE 42.2 / KDE-Plasma 5.8.2. After removing the weather widget from desktop, logging out an in the problem disappeared.
Why has this bug marked as RESOLVED WONTFIX without any comment? Last time I checked it still did not work for me.
Because the recent comments suggested it is not a plasma-nm problem.
If Plasma-NM cannot do anything to prevent that a totally unrelated widget affects how Plasma-NM works, IMO the bug's component should be changed to Plasma or whatever is responsible for separating Plasna widgets from each other instead of closing the bug. So is it a Plasma Desktop bug that Weather affects Plasma-NM? Plasma Framework?
(In reply to Christoph Feck from comment #75) > Because the recent comments suggested it is not a plasma-nm problem. Actually the bug is still present on my system. It just happens not so frequently after removing the weather widget. I'm currently running openSUSE-42.3 with KDE/Plasma 5.8.7.
This ticket is quite polluted already. I suggest that you create a new ticket with steps to reproduce with a recent plasma-nm version.