On Mon, May 20, 2013 at 2:42 AM, Martin Uhrin <martin.uhrin at gmail.com> wrote: > I'm trying to connect to our Uni VPN which I haven't done with > openconnect before so I have no idea if I can expect it to work. > > The latest failure I get is 'Failed to exec CSD script > /tmp/csdq9y1Q8'. I realise that I can supply a custom script but what > would this have to contain? The older server installations would provide a standalone CSD binary that openconnect could execute in its own process, but unfortunately this method seems to be deprecated by Cisco. On this server the Linux legacy CSD binary does not appear to be installed at all: curl -I --insecure https://vpn.ucl.ac.uk/CACHE/sdesktop/install/binaries/sfinst -> 404 Not Found On a known good server: curl -I --insecure https://vpn.mobile.unibas.ch/CACHE/sdesktop/install/binaries/sfinst -> 301 redirect to an installation script FWIW the legacy Windows binary is installed: curl -I --insecure https://vpn.ucl.ac.uk/CACHE/sdesktop/install/binaries/inst.exe -> 200 OK But that doesn't help us. So, you may want to sniff a good AnyConnect session and write a --csd-wrapper script that posts the appropriate data to the server. > POST https://vpn.ucl.ac.uk/ > Got HTTP response: HTTP/1.1 200 OK > Content-Type: text/html; charset=UTF-8 > Transfer-Encoding: chunked > Cache-Control: no-cache > Pragma: no-cache > Connection: Keep-Alive > Date: Mon, 20 May 2013 09:34:25 GMT > X-Aggregate-Auth: 1 > HTTP body chunked (-2) > XML POST enabled > GET https://vpn.ucl.ac.uk/+CSCOE+/sdesktop/wait.html > Failed to exec CSD script /tmp/csdq9y1Q8 One of the side effects of using the new "XML POST" protocol is that the server response will not provide the paths to the legacy CSD binaries, even if the binaries are present. This means that it is mandatory to use --csd-wrapper instead of --csd-user. I would be curious to know whether the legacy CSD binaries ever work properly with the newer servers. I have seen at least one case where they were present but completely non-functional.
