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
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
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
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
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
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
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
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
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
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 @@
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
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, );
> +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
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
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
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
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
20 matches
Mail list logo
