]> www.infradead.org Git - users/dwmw2/openconnect.git/commit
Add Wintun support
authorDavid Woodhouse <dwmw2@infradead.org>
Sat, 27 Mar 2021 16:17:57 +0000 (16:17 +0000)
committerDavid Woodhouse <dwmw2@infradead.org>
Wed, 31 Mar 2021 00:12:42 +0000 (01:12 +0100)
commit60d1f092e35f05217f1c96823c4f1b86c7915bbd
tree2d2fc7a67ec77da00d50f4ebaf0ded3e1a0dae07
parent5b7c053c0a8ddf876d9b31d4a1283ea66c25efab
Add Wintun support

Refactor the device discovery a little bit to accommodate it. We need
to scan the registry as we did for TAP-Windows anyway, in order to
find the TUNIDX that vpnc-script-win.js will use to configure routes.

So run through the scan as before, but *if* nothing is found and the
user specified an ifname, attempt to create a Wintun device with that
name. Then scan again and presumably we'll find it this time.

This should hopefully make it relatively harmless to existing setups
using TAP-Windows.

There's lots of memcpy here as Wintun *really* wants us to use its pool.
More thought required for that one, as it can't even handle stripping
packet headers so even if we decrypt directly into its buffer that
wouldn't be enough.

The configuration is also fairly horrid, as vpnc-script-win.js seems
to depend on the Legacy IP address being set on the interface before
it will set up the routes. Which of course assumes that there *is*
Legacy IP at all, and it isn't an IPv6-only tunnel.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Makefile.am
library.c
openconnect-internal.h
tests/list-taps.c
tun-win32.c
wintun.c [new file with mode: 0644]
wintun.h [new file with mode: 0644]
www/changelog.xml