Version: 0.9 (using KDE 4.5.90) OS: Linux After update to kde-plasma-networkmanagement-0.9-0.31.20101117 I lost ability to connect to the companys VPN using via OpenVPN. All the settings are exactly the same as they were yet conection fails I've created new connection and also tried on Fedora rawhide liveusb (KDE 4.6 RC1) to no avail. Connection attempts produce following output in /var/log/messages: Jan 8 21:42:36 localhost NetworkManager[1134]: <info> Starting VPN service 'openvpn'... Jan 8 21:42:36 localhost NetworkManager[1134]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 3617 Jan 8 21:42:36 localhost NetworkManager[1134]: <info> VPN service 'openvpn' appeared; activating connections Jan 8 21:42:36 localhost NetworkManager[1134]: <info> VPN plugin state changed: 3 Jan 8 21:42:36 localhost NetworkManager[1134]: <info> VPN connection 'BSoft Wawa' (Connect) reply received. Jan 8 21:42:36 localhost NetworkManager[1134]: <warn> VPN connection 'BSoft Wawa' failed to connect: 'No VPN secrets!'. Jan 8 21:42:36 localhost NetworkManager[1134]: <info> Policy set 'Xenos' (em2) as default for IPv4 routing and DNS. Jan 8 21:42:36 localhost NetworkManager[1134]: <info> Updating /etc/hosts with new system hostname Jan 8 21:42:42 localhost NetworkManager[1134]: <info> VPN service 'openvpn' disappeared ==================================================== Simply rolling back to the NM plasmoid from fedora14 repo (kde-plasma-networkmanagement-0.9-0.28.20101011)solves the situation Reproducible: Always Steps to Reproduce: 1. install latest knetworkmanagement-plasmoid 2. Configure openVPN connection (in my case x.509 with passwd and tls key). 3. try to conect to the vpn Actual Results: VPN icon shows status "connecting", after few seconds NM gives up and connection fails Expected Results: VPN connection is succesfull. OS: Linux (i686) release 2.6.37-1.fc15.i686 Compiler: gcc Related packages: kde-plasma-networkmanagement-0.9-0.31.20101117.fc15.i686 NetworkManager-0.8.2-3.git20101117.fc15.i686 kdebase-workspace-4.5.90-1.fc15.i686
I've tried latest update: kde-plasma-networkmanagement-0.9-0.32.20110106.fc15.i686 and the problem persist. I've tried to recreate connection once again without any change. I'm still unable to connect to the openVPN.
I have been investigating this issue and via git bisect, found that this commit is when openvpn stopped working: commit 4da8ead4333fb1bf4b71fe22dcbb2601c0ca8a31 Author: Sebastian Kügler <sebas@kde.org> Date: Tue Dec 21 17:51:02 2010 +0100 Generic mechanism for specifying secret storage type Patch 3/5 for more flexible handling of connection secret storage method. Patch by: Andrey Borzenkov <arvidjaar@gmail.com> CCMAIL:arvidjaar@gmail.com CCBUG:244416
What I have also observed is the UI shows the "Key Password" and "Password" fields as empty in a non-working version, but filled in with a working version.
I can confirm this. I store my passwords in kwallet. In the entries in kwallet manager I can see these strings: password%SEP%<actual_pasword>
(In reply to comment #3) > What I have also observed is the UI shows the "Key Password" and "Password" > fields as empty in a non-working version, but filled in with a working version. Non working connection should be fixed with https://git.reviewboard.kde.org/r/100856/. Could you file separate bug report for empty input fields and put me on Cc. Thank you.
Git commit 11645bb0c38545d343ac014f4b402244db973c16 by Lamarque V. Souza. Committed on 14/03/2011 at 20:16. Pushed by lvsouza into branch 'master'. Applying Secrets: fix missing secrets for VPN plugins without explicit storage type. Thanks Andrey Borzenkov for this patch. REVIEW: 100856 BUG: 262555 M +10 -0 libs/internals/connection.cpp M +7 -0 libs/internals/connection.h M +2 -1 libs/internals/setting.h M +5 -15 libs/internals/settings/vpn.cpp M +1 -1 libs/internals/settings/vpn.h M +1 -1 libs/internals/settings/vpnpersistence.cpp M +2 -1 libs/ui/connectionsecretsjob.cpp http://commits.kde.org/networkmanagement/11645bb0c38545d343ac014f4b402244db973c16
Confirmed, this patch solves the problem.
*** Bug 262359 has been marked as a duplicate of this bug. ***
*** Bug 241798 has been marked as a duplicate of this bug. ***
*** Bug 268385 has been marked as a duplicate of this bug. ***
*** Bug 204596 has been marked as a duplicate of this bug. ***