[Openvpn-devel] [PATCH 6/7] wintun: stop sending TAP-Windows6 ioctls to NDIS device

Wintun doesn't have its own I/O device. Rather, it taps on existing Windows-provided NDIS device. Sending TAP-Windows6 IOCTL requests to it is risky, as TAP-Windows6 is using one of the well-known device types (FILE_DEVICE_UNKNOWN) with function IDs as 1, 2, 3 etc. raising a chance of collision as

[Openvpn-devel] [PATCH 4/7] wintun: register ring buffers when iterating adapters

Wintun adapters may be considered available if ring buffer registration succeeded. Therefore, we must attempt to register ring buffers when iterating adapters and continue on failure. Signed-off-by: Simon Rozman --- src/openvpn/tun.c | 110 +++--- 1 file c

[Openvpn-devel] [PATCH 2/7] tun.c: upgrade get_device_guid() to return the Windows driver type

Signed-off-by: Simon Rozman --- src/openvpn/tun.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 053a8232..623ed37b 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -4110,6 +4110,7 @@ static const char * g

[Openvpn-devel] [PATCH 5/7] wintun: add support for --dev-node

Signed-off-by: Simon Rozman --- src/openvpn/tun.c | 38 -- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 9dc9b3a2..8508b9c0 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -6194,7 +6194,6 @

[Openvpn-devel] [PATCH 3/7] tun.c: make wintun_register_ring_buffer() non-fatal on failures

Wintun allows multiple handles to be opened on it's NDIS device pipe. Just by succeeding to open the pipe does not warrant the adapter is unused. When iterating for available Wintun adapter, we will need to try registering ring buffers with each one to actually determine which one is used and whic

[Openvpn-devel] [PATCH 7/7] tun.c: reword the at_least_one_tap_win() error

Signed-off-by: Simon Rozman --- src/openvpn/tun.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c index 8508b9c0..14ff0259 100644 --- a/src/openvpn/tun.c +++ b/src/openvpn/tun.c @@ -4031,7 +4031,7 @@ at_least_one_tap_win(const struct tap_r

[Openvpn-devel] [PATCH 1/7] tun.c: make Windows device lookup functions more general

Since the introduction of Wintun, not all network devices in Windows are TAP-Windows6. Rather than returning a simple true/false answer, a couple of functions were reworked to return a corresponding struct tap_reg * or NULL instead. As it would make the code `tr = is_tap_win(...)` a bit awkward th

[Openvpn-devel] Summary of the community meeting (19th December 2019)

Hi, Here's the summary of the IRC meeting. --- COMMUNITY MEETING Place: #openvpn-meeting on irc.freenode.net Date: Thurday 19th December 2019 Time: 20:00 CET (19:00 UTC) Planned meeting topics for this meeting were here: Your loc

[Openvpn-devel] [PATCH applied] Re: tun.c: do not add/remove routes on tun open/close

Your patch has been applied to the master branch. As discussed on the IRC meeting, I've amended the commit message to make it more clear what happened. See below. (Test built on ubuntu 1604, and also stared-at-code and asked confused questions :-) ) commit 4f2289893d9d1d448e9654b00d18e13f8fb093

[Openvpn-devel] [PATCH applied] Re: tun.c: refactor open_tun() implementation

Your patch has been applied to the master branch. I have test built on Ubuntu 1604/mingw (works). No further tests. Thanks for the refactoring. It's a good basis for further cleanup. I have *not* tried to follow this in full detail, trusting Simon on this. What I did do is verify it's all i

Re: [Openvpn-devel] [PATCH] tun.c: do not add/remove routes on tun open/close

Makes sense. I am pretty sure the interface network route is not required to be added explicitly. Acked-by: Simon Rozman Best regards, Simon > -Original Message- > From: Lev Stipakov > Sent: Thursday, December 19, 2019 12:18 PM > To: openvpn-devel@lists.sourceforge.net > Cc: Lev Stipak

[Openvpn-devel] [PATCH] options.c: do not force route delay when not using DHCP

From: Lev Stipakov Route delay may be only necessary when we perform DHCP handshake. When we use IPAPI / netsh / manual, no delay needed. Signed-off-by: Lev Stipakov --- src/openvpn/options.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/src/openvpn/o

[Openvpn-devel] [PATCH] tun.c: do not add/remove routes on tun open/close

From: Lev Stipakov Commit 1c4a47f added route manipulation to open/close tun functions, which is not really needed: - routes are added in check_add_routes(), triggered by timer - routes are removed in delete_routes(), called by do_close_tun() Signed-off-by: Lev Stipakov --- src/openvpn/rou