On Wed, 2014-02-12 at 12:11 +0100, Gert Doering wrote: > > It actually *should* work just fine.
Thanks for the response. > I've never used the control panel to set up IPv6 addresses, but using > netsh worked nicely for me (and OpenVPN) - look into the openvpn sources > to see the necessary invocations. Yeah, that's where I'd looked (and vpnc's vpnc-script-win.js, since OpenConnect is designed to spawn an identical vpnc-script with identical environment variables rather than reinventing that particular wheel). There isn't a problem with the command line. If I change 'Local Area Connection 3' to 'Local Area Connection 4', the same command line works. If I change it to a name that doesn't exist, I get a relatively sane error. If I change it in other ways to break it, I get other errors that make at least a little bit of sense. But the command that *should* work, on just the *first* interface that was created, is failing with 'Element not found'. On a Linux system I'd be able to work out what was happening and fix the issue. but with Windows I'm stuck. I know Windows tends to be horribly unreliable like this — if it's just an unlucky coincidence that it happened on the first Windows system on which I was testing my nascent OpenConnect Windows support, I can live with that. I just wanted to check whether it was something that other people were seeing. > We had our share of issues if tap adapter names included non-7bit-characters, > but that was completely different to what you are describing. Right. These just have the default names. I have yet to contemplate the true horror of the Windows so-called "Unicode" support. (And speaking of character set support, are you aware you're replying in the us-ascii charset, so the U+2014 emdash in my original mail turned into three question marks in your citation?) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
