Easier solution that also works for me here. Make sure to exchange 'openconnect' with 'vpnc' when creating the symlink.
Wow, It works! Great, now where do we report the bug? Is it a packageing bug, and the symlink should be provided by the package or is it just an ugly workaround, I can't tell.
]]>Nm-applet redirects the secrets request to GNOME Shell (when version >= 3.4 is detected), which apparently is not able to handle this without ConsoleKit.
The following patch prevent nm-applet from redirecting the request (as it is done for GNOME Shell version <3.4): fix-vpn-secret-request.patch
I also created a new pkgbuild with the above patch included: network-manager-applet.tar.xz (I didn't change pkgname or pkgver as I consider this being only for testing).
I don't think this is an appropriate final solution but it may help to identify the problem and works as a temporary fix. The drawbacks that I noticed so far are that the nm-applet shows a second icon when a VPN connection is established (this may be rather related to another problem I have with my icons and themes) and that there is no message in the notification area about the successful connection.
I've no idea if this is an Arch related or upstream problem neither if the problem is in gnome-shell, network-manager-applet or anywhere else.
Please try and report if it works for you, too.
]]>ConsoleKit is removed. This definitely broke when I upgraded to systemd as it was working previously on GNOME Shell 3.6 before the systemd upgrade.
]]>I also had the issue of vpnc not working after upgrade to 3.6. Removing consolekit seems to have solved the problem, now it's working again for me (so far...).
I removed consolekit right after the upgrade... it has something to do with permissions but I cannot figure out what exactly.
]]>ijanos, unfortunately I am using 3.6 from testing and this exists (seems to have worked fine before that). i'll try the command line vpnc.
Indeed. I've also upgraded as gnome 3.6 and the problem still exists.
I am really annoyed by this regeression, it worked flawlessy in the past, and I have no idea what causes it, or where should I report it. (It is a gnome bug, a networkmanager bug or something is fishy with the vpn client?)
]]>I can use the command line vpnc until then.
]]>#!/bin/bash -x
exec 2>&1 > /dev/null
CSD_BINARY="$1"
shift
$CSD_BINARY "$@"
This seemingly meaningless shell script makes the CSD binary execute successfully and then the VPN can connect correctly. The thing breaks terribly if I just do 'exec $CSD_BINARY "$@"', and also breaks terribly without the 'exec 2>&1 >/dev/null'. I don't really understand why it works, but it does.
Unfortunately I'm not sure this helps your case with vpnc, since this solution is *extremely* Cisco-centric.
]]>Still getting breakage in that it's not properly authenticating:
Attempting to connect to redacted:443
Using client certificate '/CN=redacted'
Client certificate expires soon at: Dec 5 02:57:05 2012 GMT
SSL negotiation with somesite.somedomain.com
Connected to HTTPS on somesite.somedomain.com
GET https://somesite.somedomain.com/
Got HTTP response: HTTP/1.0 302 Object Moved
SSL negotiation with somesite.somedomain.com
Connected to HTTPS on somesite.somedomain.com
GET https://somesite.somedomain.com/+webvpn+/index.html
GET https://somesite.somedomain.com/CACHE/sdesktop/install/binaries/sfinst
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://somesite.somedomain.com/+CSCOE+/sdesktop/wait.html
Failed to read from SSL socket
Error fetching HTTPS response
This behavior is not what I'm getting from the command-line client, of course, so... still digging.
]]>.xsession-errors wasn't capturing any messages from gnome-shell, which is why I investigated such a bizarre route to getting more data.
Strange, I'm gettin "Window manager warning"-s and various javascript error messages from gnome-shell in that file.
But still, what could be the reason behind this vpn issue? If it really is a polkit issue, how can we debug that?
]]>