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.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
