On Sun, Mar 10, 2013 at 4:49 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sun, 2013-03-10 at 19:06 +0800, Antonio Borneo wrote:
>>
>> - if (vpninfo->csd_starturl && vpninfo->csd_waiturl && vpninfo->csd_waiturl) {
>> + if (vpninfo->csd_starturl && vpninfo->csd_waiturl) {
>
> One of those was supposed to be csd_stuburl, I think.
This may work for some cases, but not all of them. On servers that
require CSD + XML POST, there is no csd_stuburl. All you get is this:
<host-scan>
<host-scan-ticket>2BE01243790D5BF2700612FD</host-scan-ticket>
<host-scan-token>312063547920F2A721E5AF66</host-scan-token>
<host-scan-base-uri>/CACHE</host-scan-base-uri>
<host-scan-wait-uri>/+CSCOE+/sdesktop/wait.html</host-scan-wait-uri>
</host-scan>
Instead of downloading and executing a single trojan binary from an
URL that is explicitly named in the XML document, the official Cisco
client invokes the locally installed hostscan module and it sort of
"does its own thing," downloading a hostscan XML configuration file, a
manifest listing DLLs and their hashes, etc.
Currently the only way to connect to such a server from openconnect is
to use a custom csd-wrapper script. In the future, somebody might
write a wrapper script that leverages (or emulates) the official Cisco
hostscan code.
So the CSD logic in the head of tree no longer works correctly with
this sort of server. You can see the failure with:
openconnect --os win -v vpn.microen.com
It will (incorrectly) skip the CSD step, and error out.
