On Tue, 2014-05-27 at 09:44 +0200, Aleksandar Kanchev wrote:
> inet_aton("255.255.255.255") would fail on windows which would
> result of the script variable INTERNAL_IP4_NETMASK not being set.
That should be fixed by
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/d8b7da1a
What is the config you get from the server? You have a VPN
address/netmask of a single Legacy IP address and 255.255.255.255, which
would basically leave you routing *nothing* to the VPN, and then you
have a set of routes to add to that?
> Another side effect is that if the TAP Windows driver is being
> initialized with 255.255.255.255 netmask then there's no way
> to convince windows to route packets through that interface.
If this isn't considered a bug in the Windows tap driver, (and I suspect
it isn't, because they're working around some true horridness in the
Windows network stack), then I think it's better to localise it to our
tun-win32.c with something like the following:
diff --git a/tun-win32.c b/tun-win32.c
index 102a7d0..b9ac163 100644
--- a/tun-win32.c
+++ b/tun-win32.c
@@ -169,6 +169,10 @@ static intptr_t open_tun(struct openconnect_info *vpninfo, char *guid, char *nam
data[0] = inet_addr(vpninfo->ip_info.addr);
data[2] = inet_addr(vpninfo->ip_info.netmask);
+ /* Ick. The Windows tap driver (or network stack) cannot cope with a netmask
+ of 255.255.255.255. */
+ if (data[2] == 0xffffffff)
+ data[2] = htonl(0xfffffffe);
data[1] = data[0] & data[2];
if (!DeviceIoControl(tun_fh, TAP_IOCTL_CONFIG_TUN,
--
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140623/bcb63c66/attachment.bin>
