Compiled, tested.
Acked-by: Lev Stipakov
PS
When you send v2 etc, could you add changelog to git mail after "---" line.
See https://patchwork.openvpn.net/patch/388/ as an example:
Signed-off-by: Antonio Quartulli
---
Changes from v2:
- patchset rebased on top of pre-ipv6-onl
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 | 111 +++---
1 file c
Hi,
+/* Wintun adapter may be considered "open" after ring buffers are
> successfuly registered. */
> +if (!wintun_register_ring_buffer(tt))
> +{
>
Here we pass incorrect handle to wintun_register_ring_buffer - tt->hand is
0 at that point,
since CreateFile value was assign
No changes since v1.
Acked-by: Lev Stipakov
pe 20. jouluk. 2019 klo 18.14 Simon Rozman (si...@rozman.si) kirjoitti:
> 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 avai
Compared with v1, difference is updated function comment.
Compiled with MSVC.
Acked-by: Lev Stipakov
pe 20. jouluk. 2019 klo 18.14 Simon Rozman (si...@rozman.si) kirjoitti:
> Signed-off-by: Simon Rozman
> ---
> src/openvpn/tun.c | 17 +
> 1 file changed, 13 insertions(+), 4 d
Compared with v1, only changes are (suggested) function names.
Compiled with MSVC.
Acked-by: Lev Stipakov
pe 20. jouluk. 2019 klo 18.14 Simon Rozman (si...@rozman.si) kirjoitti:
> Since the introduction of Wintun, not all network devices in Windows are
> TAP-Windows6. Rather than returning a s
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
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 f56682ef..18f06bb6 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -6196,7 +6196,6 @
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 | 112 +++---
1 file c
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
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 6762402c..4e16f989 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -4031,7 +4031,7 @@ at_least_one_tap_win(const struct tap_r
Signed-off-by: Simon Rozman
---
src/openvpn/tun.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 0d6f40fe..f90f201d 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -4104,12 +4104,13 @@ get_unspecified_de
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
Hi,
On Thu, Dec 19, 2019 at 11:39:11PM +0100, Simon Rozman wrote:
> 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
Makes sense, since we now support both tap-windows and wintun.
Acked-by: Lev Stipakov
pe 20. jouluk. 2019 klo 0.40 Simon Rozman (si...@rozman.si) kirjoitti:
> Signed-off-by: Simon Rozman
> ---
> src/openvpn/tun.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/ope
Hi,
@@ -688,7 +688,10 @@ x_check_status(int status,
> }
> #elif defined(_WIN32)
> /* get possible driver error from TAP-Windows driver */
> -extended_msg = tap_win_getinfo(tt, &gc);
> +if (!tt->wintun)
> +{
> +extended_msg = tap_win_getinfo(tt
Hi,
Compiled and tested, works as expected. One thing:
> +if (tun_try_open_device(tt, *device_guid,
> device_instance_id_interface))
> {
> break;
> }
>
We leak tt->hand here if we don't break - in the next loop iteration we
overwrite tt->ha
Built, tested - works as expected. Probably the first time I ran two VPN
tunnels with OpenVPN-GUI.
The code has an assumption, however, that "windows-driver" power over
"dev-node" -
if --dev-node is "OpenVPNWinTun" (for example) and "windows-driver" is not
specified, we bail out.
I would add some
Compiled with MSVC, ran under debugger - works as expected.
Acked-by: Lev Stipakov
pe 20. jouluk. 2019 klo 0.40 Simon Rozman (si...@rozman.si) kirjoitti:
> 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
Hi,
While at the moment NULL is always passed when calling get_device_guid(),
this change will be needed in 5/7 "intun: add support for --dev-node".
You (or committer :) may want to update comment, since it also returns
optional device type:
/*
* Lookup a --dev-node adapter name in the registry
Hi,
Build in MSVC, tested and ran in debugger.
The only nitpick is those methods (since you have touched them)
+get_tap_by_guid(const char *guid, const struct tap_reg *tap_reg)
+get_tap_by_name(const char *name, const struct tap_reg *tap_reg, const
struct panel_reg *panel_reg)
could be rena
21 matches
Mail list logo
