In "Network Management Settings", VPN tab, double-clicking on an existing connection name results in a very long pause (30s), followed by a popup titled "Error - Plasma Desktop Shell" containing the following text: "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." At that point the connection details may be edited. This is on a freshly installed Kubuntu 12.10 system; the version listed for plasma-widget-networkmanagement is 0.9.0.5-0ubuntu1.1. Reproducible: Always Steps to Reproduce: 1. Create a VPN connection in Network Management Settings (mine was PPTP) 2. Select it for editing by double-clicking on its name Actual Results: long pause and error popup Expected Results: immediate display of connection information edit window
This is looks like polkit or dbus denying access to NetworkManager. Is it still happening?
I still observe this issue after building and installing 0.9.0.6; however see build process description in bug 312964 and the caveat about the displayed version string - I am not sure I am testing the new code properly.
Does this happen only with VPN connections or with normal connections too? Are you able to edit the connection using root user? If it works with root user then there is a permission problem in your computer.
If you can provide the information requested in comment #3, please add it.
Thanks for the reminder, Christoph. 1) It only happens with VPN connections, not normal (Wired) connections. 2) I attempted running as root using "sudo plasmoidviewer org.kde.networkmanagement". Instead of a pause and the above error message, I got an instant error message of "No user agents were available for this request". Note that I *am* able to edit the connections - it's just that a long pause (30-40s) and an error message always precede the appearance of the connection edit window.
you must also start kded4 in the same session plasmoidviewer run since Plasma NM's secret agent run in kded4. Something like this: sudo bash kded4 & sleep 15 plasmoidviewer org.kde.networkmanagement It seems VPN connections triggers a dbus call that is being blocked somehow. We need to figure out which call is being blocked. You can also run dbus-monitor | tee log.txt while testing this problem (no need to use root in this case). Then compress and send the log.txt file. It can contain some clues about which call is being blocked.
Unfortunately kded4 does not like to run when another instance is present: QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. KDE Daemon (kded) already running. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. [1]+ Done kded4
Created attachment 77304 [details] output of dbus-monitor containing the 30s hang window Per request. I hadn't noticed the previous comment that running as root is not required.
Lamarque, is the information from comment #8 and above sufficient to further investigate this issue?
By the line with "method call sender=:1.116 -> dest=org.kde.kwalletd serial=22 path=/modules/kwalletd; interface=org.kde.KWallet; member=isEnabled" I guess NetworkManager reached Plasma NM's secret agent. Can you also attach the ~/.xsession-errors file so I can see the secret agent's debug messages too? Please enable the debug messages using kdebugdialog prior to reproducing the problem (search for the string "network", then mark all checkboxes that will appear, then click Ok button).
Created attachment 77762 [details] .xsession-errors fragment bracketing this issue
Created attachment 77763 [details] dbus-monitor output matching the new xsession-errors just in case there is some variation from the original
While preparing the requested data I happened to notice that having nm-applet running makes this problem go away! It's quite repeatable...
Git commit d05ffbae79b205881c7704e23de32da17550a625 by Lamarque V. Souza. Committed on 05/03/2013 at 14:28. Pushed by lvsouza into branch 'master'. Add some debug messages. M +1 -0 backends/NetworkManager/connectiondbus.cpp M +3 -0 backends/NetworkManager/nmdbussecretagent.cpp http://commits.kde.org/networkmanagement/d05ffbae79b205881c7704e23de32da17550a625
Git commit dbc079ec3d831c93af8a57e490f446546bc3dc92 by Lamarque V. Souza. Committed on 05/03/2013 at 14:28. Pushed by lvsouza into branch 'nm09'. Add some debug messages. (cherry picked from commit d05ffbae79b205881c7704e23de32da17550a625) M +1 -0 backends/NetworkManager/connectiondbus.cpp M +3 -0 backends/NetworkManager/nmdbussecretagent.cpp http://commits.kde.org/networkmanagement/dbc079ec3d831c93af8a57e490f446546bc3dc92
the .xsession-errors log is not conclusive, I added some more debug messages to help me identify what could be happening. Can you 'git pull', recompile networkmanagement and repeat the test?
One explanation for this problem is if there is a problem in kwallet. By the dbus log kwallet is enabled, but if the KWallet::open() call never emits the "kwallet opened for read" signal then that could explain this problem. Since the kDebug() message in SecretStorage::walletOpenedForRead() is neer printed then it looks like there is a problem in kwallet.
For what it's worth, I have the password etc. set to always prompt me, and to not use kwallet. Is there a reason kwallet should be involved in editing a connection? I will try to build from git.
Yes, kwallet is the default secret storage for Plasma NM and when editing a connection Plasma NM's secret agent always tries to retrieve the secrets from kwallet or the plain text file. Checking if the secret is set to "always prompt" before opening kwallet is possible but very troublesome so it is not implemented. Did you disabled kwallet? If so then it is strange that the "is wallet enabled" call returned true. Hmmm in your second dbus log there is no indication of kwallet. If you do not use kwallet you must change Plasma NM's configuration to use "plain text" storage in "Manage Connections" -> Other -> Store connection strecrets: in file (unencrypted). I really do recommend using kwallet. Any other storage type is not well tested like kwallet.
Hi Lamarque, it is my wish to not use *any* storage mechanism, and I don't. Accordingly that option is set to "Do not store (always prompt)". Is it mandatory to set that to "plain text", even though I am not storing passwords?
Also I'm afraid I need some help compiling networkmanager... CMake fails trying to find QtModemManager. I run the same way I previously have: mkdir build;cd build;cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` .. using the code I got this way: git clone git://anongit.kde.org/networkmanagement Specific build directions would really help.
Created attachment 77973 [details] .xsession-errors when nm-applet is running It still seems significant to me that this issue does not occur when nm-applet is running. It's not really doing anything at all - I just bring it up but am not using it. Nevertheless plasma network manager responds immediately to my request to edit the VPN connection, without pausing or producing an error message.
Created attachment 77974 [details] dbus-monitor output when nm-applet is running In case the disappearance of this issue when nm-applet is running is a clue to what's happening.
This issue is still present in Version 0.9.0.8 (nm09 20130310).
Plasma 0.9.0.x is not maintained anymore. Can you upgrade to version 0.9.3.x and report if the still happens?
Unfortunately in the 2.5 years since I reported this bug I have changed jobs, and am no longer using VPN for anything. I no longer am able to perform experiments to gather data about the bug. It is possible that it has been fixed in the meantime, I suppose...