date:20200205

Re: [Openvpn-devel] [PATCH] tun.c: uncrustify

2020-02-05 Thread Lev Stipakov

I trust uncrustify to do the right thing :)

Compiled, smoke-tested.

Note to committer: this patch should be applied before
https://patchwork.openvpn.net/patch/978/ (wintun: upgrade error message in
case of ring registration failure).

Acked-by: Lev Stipakov 
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Fix linking issues on MinGW

2020-02-05 Thread Gert Doering

Your patch has been applied to the master branch.

I have slightly modified the commit message to explain the underlying
issue better ("if compiled without -O2").  No change code-wise to your
patch.  Makes sense :-)

commit 5822e52c6b0f86f9e4de946f9fb1374c6fad95f1
Author: Domagoj Pensa
Date:   Wed Feb 5 13:46:15 2020 +0100

 Fix linking issues on MinGW

 Signed-off-by: Domagoj Pensa 
 Acked-by: Lev Stipakov 
 Message-Id: <20200205124615.15758-3-doma...@pensa.hr>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19356.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] tun.c: refactor driver detection and make it case-insensitive

2020-02-05 Thread Lev Stipakov

Hi,

Indeed, looks much easier to read.

Compiled, tested.

Acked-by: Lev Stipakov 
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] wintun: upgrade error message in case of ring registration failure

2020-02-05 Thread Lev Stipakov

Hi,

-msg(M_NONFATAL, "Failed to register ring buffers: %lu",
> GetLastError());
>


> +switch (GetLastError())
>


> +default:
> +msg(M_NONFATAL | M_ERRNO, "Failed to register ring
> buffers");
>

I think it would make sense to print the error code / error message (with
strerror_win32) in the "default" case.
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] wintun: check for conflicting options

2020-02-05 Thread Lev Stipakov

Makes sense.

Compiled, tested.

Acked-by: Lev Stipakov 
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] wintun: check for conflicting options

2020-02-05 Thread Simon Rozman

`--windows-driver wintun` requires `--dev tun`. This is now checked and
documented.

Signed-off-by: Simon Rozman 
---
 doc/openvpn.8 | 4 
 src/openvpn/options.c | 7 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 8feb3b9c..e2227a47 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -6257,6 +6257,10 @@ Specifies which tun driver to use. Values are
 (default) and
 .B wintun.
 This is Windows-only option.
+"wintun" requires
+.B \-\-dev tun
+and the OpenVPN process to run elevated, or be invoked using
+the Interactive Service.
 .\"*
 .TP
 .B \-\-dhcp\-renew
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index c459b260..101cca38 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -2204,7 +2204,12 @@ options_postprocess_verify_ce(const struct options 
*options, const struct connec
 {
 msg(M_USAGE, "--dhcp-options requires --ip-win32 dynamic or adaptive");
 }
-#endif
+
+if (options->windows_driver == WINDOWS_DRIVER_WINTUN && dev != 
DEV_TYPE_TUN)
+{
+msg(M_USAGE, "--windows-driver wintun requires --dev tun");
+}
+#endif /* ifdef _WIN32 */
 
 /*
  * Check that protocol options make sense.
-- 
2.24.1.windows.2



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] wintun: upgrade error message in case of ring registration failure

2020-02-05 Thread Simon Rozman

Rather than have the Interactive Service return a custom 0x2004
(ERROR_REGISTER_RING_BUFFERS) error, return the true GetLastError() code
that the TUN_IOCTL_REGISTER_RINGS provides.

Signed-off-by: Simon Rozman 
---
 src/openvpn/ring_buffer.h |  2 +-
 src/openvpn/tun.c | 18 +++---
 src/openvpnserv/interactive.c |  3 +--
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/src/openvpn/ring_buffer.h b/src/openvpn/ring_buffer.h
index 3522c984..af46f106 100644
--- a/src/openvpn/ring_buffer.h
+++ b/src/openvpn/ring_buffer.h
@@ -92,7 +92,7 @@ struct TUN_PACKET
  *that data is available for reading in send ring
  * @param receive_tail_moved  event set by openvpn to signal wintun
  *that data has been written to receive ring
- * @returntrue if registration is successful, false 
otherwise
+ * @returntrue if registration is successful, false 
otherwise - use GetLastError()
  */
 bool register_ring_buffers(HANDLE device,
struct tun_ring *send_ring,
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index af09e676..27fcb785 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5943,7 +5943,7 @@ tuntap_set_ip_addr(struct tuntap *tt,
 }
 
 static bool
-wintun_register_ring_buffer(struct tuntap *tt)
+wintun_register_ring_buffer(struct tuntap *tt, const char *device_guid)
 {
 bool ret = true;
 
@@ -5975,7 +5975,19 @@ wintun_register_ring_buffer(struct tuntap *tt)
 tt->rw_handle.read,
 tt->rw_handle.write))
 {
-msg(M_NONFATAL, "Failed to register ring buffers: %lu", 
GetLastError());
+switch (GetLastError())
+{
+case ERROR_ACCESS_DENIED:
+msg(M_FATAL, "Access denied registering ring buffers. Is 
this process run as SYSTEM?");
+break;
+
+case ERROR_ALREADY_INITIALIZED:
+msg(M_NONFATAL, "Adapter %s is already in use", 
device_guid);
+break;
+
+default:
+msg(M_NONFATAL | M_ERRNO, "Failed to register ring 
buffers");
+}
 ret = false;
 }
 if (!RevertToSelf())
@@ -6197,7 +6209,7 @@ tun_try_open_device(struct tuntap *tt, const char 
*device_guid, const struct dev
 if (tt->windows_driver == WINDOWS_DRIVER_WINTUN)
 {
 /* Wintun adapter may be considered "open" after ring buffers are 
successfuly registered. */
-if (!wintun_register_ring_buffer(tt))
+if (!wintun_register_ring_buffer(tt, device_guid))
 {
 msg(D_TUNTAP_INFO, "Failed to register %s adapter ring buffers", 
device_guid);
 CloseHandle(tt->hand);
diff --git a/src/openvpnserv/interactive.c b/src/openvpnserv/interactive.c
index 6e72a141..5b250225 100644
--- a/src/openvpnserv/interactive.c
+++ b/src/openvpnserv/interactive.c
@@ -51,7 +51,6 @@
 #define ERROR_STARTUP_DATA   0x2001
 #define ERROR_MESSAGE_DATA   0x2002
 #define ERROR_MESSAGE_TYPE   0x2003
-#define ERROR_REGISTER_RING_BUFFERS  0x2004
 
 static SERVICE_STATUS_HANDLE service;
 static SERVICE_STATUS status = { .dwServiceType = SERVICE_WIN32_SHARE_PROCESS 
};
@@ -1308,8 +1307,8 @@ HandleRegisterRingBuffers(const 
register_ring_buffers_message_t *rrb, HANDLE ovp
 if (!register_ring_buffers(ring_buffer_handles->device, send_ring, 
receive_ring,
ring_buffer_handles->send_tail_moved, 
ring_buffer_handles->receive_tail_moved))
 {
+err = GetLastError();
 MsgToEventLog(M_SYSERR, TEXT("Could not register ring buffers"));
-err = ERROR_REGISTER_RING_BUFFERS;
 }
 
 return err;
-- 
2.24.1.windows.2



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] tun.c: uncrustify

2020-02-05 Thread Simon Rozman

Signed-off-by: Simon Rozman 
---
 src/openvpn/tun.c | 117 +++---
 src/openvpn/tun.h |   8 ++--
 2 files changed, 63 insertions(+), 62 deletions(-)

diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 070b0fa0..47c3088d 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -817,7 +817,7 @@ init_tun_post(struct tuntap *tt,
 tt->rw_handle.read = tt->reads.overlapped.hEvent;
 tt->rw_handle.write = tt->writes.overlapped.hEvent;
 }
-#endif
+#endif /* ifdef _WIN32 */
 }
 
 #if defined(_WIN32)\
@@ -1397,18 +1397,18 @@ do_ifconfig_ipv4(struct tuntap *tt, const char *ifname, 
int tun_mtu,
 {
 switch (tt->options.ip_win32_type)
 {
-case IPW32_SET_MANUAL:
-msg(M_INFO,
-" NOTE:  Please manually set the IP/netmask of 
'%s' to %s/%s (if it is not already set)",
-ifname, ifconfig_local,
-print_in_addr_t(tt->adapter_netmask, 0, ));
-break;
-
-case IPW32_SET_NETSH:
-netsh_ifconfig(>options, ifname, tt->local,
-   tt->adapter_netmask, NI_IP_NETMASK|NI_OPTIONS);
-
-break;
+case IPW32_SET_MANUAL:
+msg(M_INFO,
+" NOTE:  Please manually set the IP/netmask of 
'%s' to %s/%s (if it is not already set)",
+ifname, ifconfig_local,
+print_in_addr_t(tt->adapter_netmask, 0, ));
+break;
+
+case IPW32_SET_NETSH:
+netsh_ifconfig(>options, ifname, tt->local,
+   tt->adapter_netmask, 
NI_IP_NETMASK|NI_OPTIONS);
+
+break;
 }
 }
 }
@@ -3481,7 +3481,7 @@ tun_finalize(
 }
 
 static const struct device_instance_id_interface *
-get_device_instance_id_interface(struct gc_arena* gc)
+get_device_instance_id_interface(struct gc_arena *gc)
 {
 HDEVINFO dev_info_set;
 DWORD err;
@@ -3552,7 +3552,7 @@ get_device_instance_id_interface(struct gc_arena* gc)
 }
 
 cr = CM_Get_Device_Interface_List_Size(_interface_list_size,
-   (LPGUID)& GUID_DEVINTERFACE_NET,
+   (LPGUID)_DEVINTERFACE_NET,
device_instance_id,

CM_GET_DEVICE_INTERFACE_LIST_PRESENT);
 
@@ -3562,7 +3562,7 @@ get_device_instance_id_interface(struct gc_arena* gc)
 }
 
 dev_interface_list = alloc_buf_gc(dev_interface_list_size, gc);
-cr = CM_Get_Device_Interface_List((LPGUID)& GUID_DEVINTERFACE_NET, 
device_instance_id,
+cr = CM_Get_Device_Interface_List((LPGUID)_DEVINTERFACE_NET, 
device_instance_id,
   BPTR(_interface_list),
   dev_interface_list_size,
   
CM_GET_DEVICE_INTERFACE_LIST_PRESENT);
@@ -3571,7 +3571,7 @@ get_device_instance_id_interface(struct gc_arena* gc)
 goto next;
 }
 
-struct device_instance_id_interface* dev_if;
+struct device_instance_id_interface *dev_if;
 ALLOC_OBJ_CLEAR_GC(dev_if, struct device_instance_id_interface, gc);
 dev_if->net_cfg_instance_id = string_alloc(net_cfg_instance_id, gc);
 dev_if->device_interface_list = 
string_alloc(BSTR(_interface_list), gc);
@@ -3587,7 +3587,7 @@ get_device_instance_id_interface(struct gc_arena* gc)
 }
 last = dev_if;
 
-next:
+next:
 RegCloseKey(dev_key);
 }
 
@@ -3694,8 +3694,8 @@ get_tap_reg(struct gc_arena *gc)
 {
 /* Is this adapter supported? */
 enum windows_driver_type windows_driver = 
WINDOWS_DRIVER_UNSPECIFIED;
-if (strcasecmp(component_id, TAP_WIN_COMPONENT_ID) == 0 ||
-strcasecmp(component_id, "root\\" 
TAP_WIN_COMPONENT_ID) == 0)
+if (strcasecmp(component_id, TAP_WIN_COMPONENT_ID) == 0
+|| strcasecmp(component_id, "root\\" 
TAP_WIN_COMPONENT_ID) == 0)
 {
 windows_driver = WINDOWS_DRIVER_TAP_WINDOWS6;
 }
@@ -5768,8 +5768,8 @@ tuntap_get_version_info(const struct tuntap *tt)
 DWORD len;
 CLEAR(info);
 if (DeviceIoControl(tt->hand, TAP_WIN_IOCTL_GET_VERSION,
-, sizeof(info),
-, sizeof(info), , NULL))
+, sizeof(info),
+, sizeof(info), , NULL))
 {
 msg(D_TUNTAP_INFO, "TAP-Windows Driver Version %d.%d %s",
 (int)info[0],
@@ -5808,8 +5808,8 @@ tuntap_get_mtu(struct tuntap *tt)
 ULONG mtu = 0;
 DWORD len;
 if (DeviceIoControl(tt->hand,

[Openvpn-devel] [PATCH] tun.c: refactor driver detection and make it case-insensitive

2020-02-05 Thread Simon Rozman

Hardware IDs are case insensitive on Windows.

Furthermore the driver detection logic has been made more explicit and
easier to read.

Signed-off-by: Simon Rozman 
---
 src/openvpn/tun.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index af09e676..070b0fa0 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -3692,11 +3692,19 @@ get_tap_reg(struct gc_arena *gc)
 
 if (status == ERROR_SUCCESS && data_type == REG_SZ)
 {
+/* Is this adapter supported? */
 enum windows_driver_type windows_driver = 
WINDOWS_DRIVER_UNSPECIFIED;
+if (strcasecmp(component_id, TAP_WIN_COMPONENT_ID) == 0 ||
+strcasecmp(component_id, "root\\" 
TAP_WIN_COMPONENT_ID) == 0)
+{
+windows_driver = WINDOWS_DRIVER_TAP_WINDOWS6;
+}
+else if (strcasecmp(component_id, WINTUN_COMPONENT_ID) == 
0)
+{
+windows_driver = WINDOWS_DRIVER_WINTUN;
+}
 
-if ((windows_driver = WINDOWS_DRIVER_TAP_WINDOWS6, 
!strcmp(component_id, TAP_WIN_COMPONENT_ID))
-|| (windows_driver = WINDOWS_DRIVER_TAP_WINDOWS6, 
!strcmp(component_id, "root\\" TAP_WIN_COMPONENT_ID))
-|| (windows_driver = WINDOWS_DRIVER_WINTUN, 
!strcmp(component_id, WINTUN_COMPONENT_ID)))
+if (windows_driver != WINDOWS_DRIVER_UNSPECIFIED)
 {
 struct tap_reg *reg;
 ALLOC_OBJ_CLEAR_GC(reg, struct tap_reg, gc);
-- 
2.24.1.windows.2



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Fwd: [PATCH 2/2] Fix linking issues on MinGW

2020-02-05 Thread Lev Stipakov

Hi,

Good catch. "Inline" generates inline definition and if we don't do
inlining
(by not specifying O2), linker doesn't see it and prints an error.
Apparently MSVC
is lax on that.

Checking source code, most (if all?) or inline methods are static.

Obviously we want our code to compile without O2, so ACK from me.

Acked-by: Lev Stipakov 

ke 5. helmik. 2020 klo 17.41 Domagoj Pensa (doma...@pensa.hr) kirjoitti:

> Hi,
>
> On Wed, Feb 05, 2020 at 10:28:38AM -0500, Selva Nair wrote:
> > Are you building without optimization? Please try using the latest
> > openvpn-build (or just add -O2 to complier options).
>
> Yes, that was it!
>
> When Lev said that he doesn't have problems with build, I've noticed that
> he
> is using script build-complete from windows-nsis.
>
> I didn't want installer build, just binaries, so I followed  instructions
> from README and generic/README and thus I used generic/build.
>
> But that doesn't include -O2 and I get mentioned error when linking.
>
> In windows-nsis/build-complete there are additional flags "-O2 -flto" and
> that's why Lev doesn't have issues and we are using same tools and OS
> versions.
>
> Those additional flags where added by Lev in commit 3eb61bb in
> openvpn-build.
>
> Problem solved, now I know for the future.
>
> But still it would be nice to somehow "fix" this for others, by either
> updating READMEs, adding -O2 to generic/build script or apply patch I've
> sent that helped me and links with optimization off.
>
> Maybe doing all that won't be bad.
>
> Thank you all!
>
> Domagoj
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>


-- 
-Lev
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/2] Skip DNS address validation

2020-02-05 Thread Selva Nair

Hi,

On Wed, Feb 5, 2020 at 10:28 AM Lev Stipakov  wrote:
>
> Hi,
>
> Built and tested with msvc, works as expected - "validate=no" is added to 
> netsh command line.
>
> There is a similar commit in Simon's repo (not yet sent to ml) : 
> https://github.com/rozmansi/openvpn/commit/6b746cb0bf72a75e9963cc1a037c18cfb856702a
>
> I haven't noticed any slowness on my machine, but since fix has been 
> implemented separately
> by two persons and there is similar code for ipv6, I am ok with that.

>
> Acked-by: Lev Stipakov 

We explicitly added validate=no for IPv6 in
commit 786e06ade9f5dfad8ac360499187fa8e536d15cb
for the same reason as in this patch. The ipv4 DNS code belongs to an
era when this
option was not available.

ACK from me too.


Selva

>
> Acked-by: Lev Stipakov 
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Fwd: [PATCH 2/2] Fix linking issues on MinGW

2020-02-05 Thread Domagoj Pensa

Hi,

On Wed, Feb 05, 2020 at 10:28:38AM -0500, Selva Nair wrote:
> Are you building without optimization? Please try using the latest
> openvpn-build (or just add -O2 to complier options).

Yes, that was it!

When Lev said that he doesn't have problems with build, I've noticed that he 
is using script build-complete from windows-nsis.

I didn't want installer build, just binaries, so I followed  instructions 
from README and generic/README and thus I used generic/build.

But that doesn't include -O2 and I get mentioned error when linking.

In windows-nsis/build-complete there are additional flags "-O2 -flto" and 
that's why Lev doesn't have issues and we are using same tools and OS 
versions.

Those additional flags where added by Lev in commit 3eb61bb in 
openvpn-build.

Problem solved, now I know for the future.

But still it would be nice to somehow "fix" this for others, by either 
updating READMEs, adding -O2 to generic/build script or apply patch I've 
sent that helped me and links with optimization off.

Maybe doing all that won't be bad.

Thank you all!

Domagoj

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Fwd: [PATCH 2/2] Fix linking issues on MinGW

2020-02-05 Thread Selva Nair

-- Forwarded message -
From: Selva Nair 
Date: Wed, Feb 5, 2020 at 10:16 AM
Subject: Re: [Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW
To: Domagoj Pensa 
Cc: Gert Doering 

Hi,

On Wed, Feb 5, 2020 at 8:31 AM Domagoj Pensa  wrote:
>
> Hi!
>
> On Wed, Feb 05, 2020 at 02:05:11PM +0100, Gert Doering wrote:
> > Hi,
> >
> > On Wed, Feb 05, 2020 at 01:46:15PM +0100, Domagoj Pensa wrote:
> > > MinGW linking fails for several files due to a missing "static"
> > > declaration in functions tuntap_is_wintun() and tuntap_ring_empty().
> >
> >

Are you building without optimization? Please try using the latest
openvpn-build (or just add -O2 to complier options).

I suspect this is caused by the fact that gcc does not inline when
optimization is not on, but also not generating exported code in that
case. Inline implementation in gcc has so many subtleties, so not sure
whether this is a compiler bug or "feature".

Adding a static appears to be not a bad solution as gcc will emit
external code for static inline functions only if necessary.

Selva

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 1/2] Skip DNS address validation

2020-02-05 Thread Lev Stipakov

Hi,

Built and tested with msvc, works as expected - "validate=no" is added to
netsh command line.

There is a similar commit in Simon's repo (not yet sent to ml) :
https://github.com/rozmansi/openvpn/commit/6b746cb0bf72a75e9963cc1a037c18cfb856702a


I haven't noticed any slowness on my machine, but since fix has been
implemented separately
by two persons and there is similar code for ipv6, I am ok with that.

Acked-by: Lev Stipakov 
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW

2020-02-05 Thread Domagoj Pensa

Hi!

On Wed, Feb 05, 2020 at 02:05:11PM +0100, Gert Doering wrote:
> Hi,
> 
> On Wed, Feb 05, 2020 at 01:46:15PM +0100, Domagoj Pensa wrote:
> > MinGW linking fails for several files due to a missing "static"
> > declaration in functions tuntap_is_wintun() and tuntap_ring_empty().
> 
> It does not fail for us.  So what MinGW version on what OS are you using
> to exhibit this error?

I've mentioned that in first mail:

I'm using Ubuntu 19.04 with mingw-w64 from official repository (version 
6.0.0-3) and for build process script generic/build from openvpn-build 
repository.

I've also included linker output same mail:

/usr/bin/x86_64-w64-mingw32-ld: forward.o:forward.c:(.text+0x5fec): 
undefined reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x8a4): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1362): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1379): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0x536): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0xf53): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x1b6): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x261): undefined 
reference to `tuntap_is_wintun'
collect2: error: ld returned 1 exit status

Here are versions for some tools from that package:

$ /usr/bin/x86_64-w64-mingw32-ld -v
GNU ld (GNU Binutils) 2.32

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir='/usr/include' --mandir='/usr/share/man' 
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' 
--libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode 
--disable-dependency-tracking --prefix=/usr --enable-shared --enable-static 
--disable-multilib --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes 
--with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include 
--enable-version-specific-runtime-libs --enable-fully-dynamic-string 
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto 
--with-plugin-ld --enable-threads=win32 --program-suffix=-win32 
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 
--with-as=/usr/bin/x86_64-w64-mingw32-as 
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
Thread model: win32
gcc version 8.3-win32 20190406 (GCC)

Domagoj


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW

2020-02-05 Thread Domagoj Pensa

Hi!

On Wed, Feb 05, 2020 at 02:05:11PM +0100, Gert Doering wrote:
> Hi,
> 
> On Wed, Feb 05, 2020 at 01:46:15PM +0100, Domagoj Pensa wrote:
> > MinGW linking fails for several files due to a missing "static"
> > declaration in functions tuntap_is_wintun() and tuntap_ring_empty().
> 
> It does not fail for us.  So what MinGW version on what OS are you using
> to exhibit this error?

I've mentioned that in first mail:

I'm using Ubuntu 19.04 with mingw-w64 from official repository (version 
6.0.0-3) and for build process script generic/build from openvpn-build 
repository.

I've also included linker output same mail:

/usr/bin/x86_64-w64-mingw32-ld: forward.o:forward.c:(.text+0x5fec): 
undefined reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x8a4): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1362): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1379): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0x536): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0xf53): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x1b6): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x261): undefined 
reference to `tuntap_is_wintun'
collect2: error: ld returned 1 exit status

Here are versions for some tools from that package:

$ /usr/bin/x86_64-w64-mingw32-ld -v
GNU ld (GNU Binutils) 2.32

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir='/usr/include' --mandir='/usr/share/man' 
--infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' 
--libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode 
--disable-dependency-tracking --prefix=/usr --enable-shared --enable-static 
--disable-multilib --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes 
--with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include 
--enable-version-specific-runtime-libs --enable-fully-dynamic-string 
--enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto 
--with-plugin-ld --enable-threads=win32 --program-suffix=-win32 
--program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 
--with-as=/usr/bin/x86_64-w64-mingw32-as 
--with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic
Thread model: win32
gcc version 8.3-win32 20190406 (GCC)

Domagoj



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW

2020-02-05 Thread Gert Doering

Hi,

On Wed, Feb 05, 2020 at 01:46:15PM +0100, Domagoj Pensa wrote:
> MinGW linking fails for several files due to a missing "static"
> declaration in functions tuntap_is_wintun() and tuntap_ring_empty().

It does not fail for us.  So what MinGW version on what OS are you using
to exhibit this error?

(The change might still make sense, but the explanation does not
make much sense - exporting a function which is not needed "outside"
should never cause a link fail)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW

2020-02-05 Thread Domagoj Pensa

MinGW linking fails for several files due to a missing "static"
declaration in functions tuntap_is_wintun() and tuntap_ring_empty().

Signed-off-by: Domagoj Pensa 
---
 src/openvpn/tun.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h
index 97d28f45..327d7927 100644
--- a/src/openvpn/tun.h
+++ b/src/openvpn/tun.h
@@ -224,13 +224,13 @@ tuntap_defined(const struct tuntap *tt)
 }
 
 #ifdef _WIN32
-inline bool
+static inline bool
 tuntap_is_wintun(struct tuntap *tt)
 {
 return tt && tt->windows_driver == WINDOWS_DRIVER_WINTUN;
 }
 
-inline bool
+static inline bool
 tuntap_ring_empty(struct tuntap *tt)
 {
 return tuntap_is_wintun(tt) && (tt->wintun_send_ring->head == 
tt->wintun_send_ring->tail);
-- 
2.25.0




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 1/2] Skip DNS address validation

2020-02-05 Thread Domagoj Pensa

When adding IPv4 DNS servers without interactive service use
"validate=no", on Windows 7 and higher, to skip time consuming automatic
address validation, that is on by default.

Fix uses adapted code from commit 786e06a

Signed-off-by: Domagoj Pensa 
---
 src/openvpn/tun.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index af09e676..9f369f74 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -5216,6 +5216,7 @@ netsh_ifconfig_options(const char *type,
 struct gc_arena gc = gc_new();
 struct argv argv = argv_new();
 bool delete_first = false;
+bool is_dns = !strcmp(type, "dns");
 
 /* first check if we should delete existing DNS/WINS settings from TAP 
interface */
 if (test_first)
@@ -5259,6 +5260,14 @@ netsh_ifconfig_options(const char *type,
 type,
 flex_name,
 print_in_addr_t(addr_list[i], 0, ));
+
+/* disable slow address validation on Windows 7 and higher */
+/* only for DNS */
+if (is_dns && win32_version_info() >= WIN_7)
+{
+argv_printf_cat(, "%s", "validate=no");
+}
+
 netsh_command(, 2, M_FATAL);
 
 ++count;
-- 
2.25.0




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 0/2] Couple of fixes

2020-02-05 Thread Domagoj Pensa

Hi!

First patch fixes long delays when setting IPv4 DNS using netsh without 
interactive service by adding "validate=no" to netsh invocation.

I've noticed that issue while testing wintun, as it is setup using netsh.

All other variants, IPv6 DNS without interactive service and IPv4/IPv6 DNS 
with interactive service, have validation already turned off.

Change is adapted from code by commit 786e06a.
It is necessary to make sure that argument is added only for DNS and not 
WINS, thus additional check is made (is_dns).

Second patch was necessary, at least for me, because build process was 
unable to perform linking, with the following output:

/usr/bin/x86_64-w64-mingw32-ld: forward.o:forward.c:(.text+0x5fec): 
undefined reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x8a4): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1362): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1379): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0x536): undefined 
reference to `tuntap_is_wintun'
/usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0xf53): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x1b6): undefined 
reference to `tuntap_ring_empty'
/usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x261): undefined 
reference to `tuntap_is_wintun'
collect2: error: ld returned 1 exit status

After declaring both functions as static linking worked.

I'm using Ubuntu 19.04 with mingw-w64 from official repository (version 
6.0.0-3) and for build process script generic/build from openvpn-build 
repository.

It is also worth noting that similar function tuntap_defined() with same 
signature (static inline bool) already exists in the same header file, so 
this change should be safe.

Domagoj Pensa (2):
  Skip DNS address validation
  Fix linking issues on MinGW

 src/openvpn/tun.c | 9 +
 src/openvpn/tun.h | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

-- 
2.25.0




___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Summary of the community meeting (5th February 2020)

2020-02-05 Thread Samuli Seppänen

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wed 5th February 2020
Time: 11:30 CET (10:30 UTC)

Planned meeting topics for this meeting were here:



Your local meeting time is easy to check from services such as



SUMMARY

cron2, mattock and syzzer participated in this meeting.

---

Cron2 tried to do the argv patchset, but it needs a rebase + tun.c
adjustments from dazo.

---

Decided to start signing tags in tap-windows6 repository as suggested here:



Mattock will use his personal key for signing.

Also noted that it might be a good idea to sign our personal GPG keys
with the security mailing list key.

---

Noted that OSTIF wants to do an audit of "changes between 2.4.0 and
2.5.0". They were fine with postponing the audit until 2.5.0 is ready -
the original tentative deadline for first 2.5 alpha - "end of January
2020" - was not met.

---

Decided to ask dazo, ordex and plaisthos what their suggestion is for
the new tentative deadline for first 2.5 alpha is. Much of the remaining
work depends on them.

Also noted that MSI installers are not a hard dependency for the 2.5
release, but not having them would mean having to support NSIS for the
entire lifetime of 2.5, which is not nice. We'll revisit this topic if
the other missing pieces are completed before MSI and MSI starts
blocking the release.

--

Full chatlog attached

(12:30:34) mattock: ok, meeting time it is
(12:30:37) mattock: I have 30 minutes to spare
(12:30:54) mattock: who has joined our merry group today?
(12:31:16) ***cron2 !
(12:33:03) mattock: lev__, ordex, plaisthos, syzzer, rozmansi?
(12:33:07) cron2: not much to report, though... I tried to do the argv 
patchset, but it needs a rebase + tun.c adjustments, and dazo went into 
hiding...
(12:33:09) mattock: dazo said he can't make it
(12:33:26) mattock: I have a couple of small topics
(12:33:37) cron2: nice, useful meeting then :)
(12:33:54) mattock: #2 Signing tap-windows6 tags 
(12:33:59) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2020-02-05
(12:34:00) vpnHelper: Title: Topics-2020-02-05 – OpenVPN Community (at 
community.openvpn.net)
(12:34:04) mattock: https://github.com/OpenVPN/tap-windows6/issues/101
(12:34:05) vpnHelper: Title: Not able to verify source code. Push signed git 
tags? · Issue #101 · OpenVPN/tap-windows6 · GitHub (at github.com)
(12:34:22) mattock: I believe we do sign the tags for openvpn.git
(12:34:23) cron2: I've seen the issue and I whould agree that this is useful
(12:34:25) cron2: yes
(12:34:32) mattock: which key do we use for signing?
(12:34:38) mattock: security key or somebody's own key?
(12:34:41) cron2: my personal key
(12:34:45) mattock: ok
(12:34:51) cron2: because it's *me* who attests that this is what I pushed
(12:34:55) mattock: yes
(12:35:16) mattock: I can make signing the tags a part of the tap-windows6 
release process, i.e. sign with my key
(12:35:44) mattock: I think that covers that topic
(12:35:46) cron2: my key is signed by "all of you", but it might be an idea to 
use the security@ key to sign the personal keys
(12:36:08) mattock: yep, would not hurt
(12:36:15) cron2: so the link "this personal key indeed belongs to someone who 
is trusted by 'the organization'" is there
(12:36:32) mattock: indeed
(12:37:14) mattock: so I shall start signing tap-windows6 tags and we can 
improve the web of trust of our keys by signing our respective personal keys
(12:37:22) mattock: another topic I forgot to add to the topic list
(12:38:31) mattock: OSTIF wants to do an audit of "changes between 2.4.0 and 
2.5.0"
(12:38:53) mattock: I probably gave them our original estimate ("first alpha at 
the end of January")
(12:39:12) mattock: they were ok with postponing the audit until 2.5.0 is ready
(12:39:26) cron2: nice
(12:39:58) mattock: not much more on that, except that we'd need to make 2.5.0 
ready :D
(12:42:24) mattock: anything else today?
(12:42:41) mattock: oh
(12:42:49) cron2: missing plaisthos, dazo, syzzer, lev__, rozmansi...
(12:42:52) cron2: how's msi coming along?
(12:43:04) mattock: community.openvpn.net is not longer a "PenVPN" site
(12:43:11) mattock: https://community.openvpn.net/
(12:43:13) vpnHelper: Title: OpenVPN Community (at community.openvpn.net)
(12:43:15) mattock: logo changed
(12:43:33) mattock: I have no knowledge of the progress of the MSI
(12:43:45) mattock: we'd need to activate rozmansi for that
(12:43:59) mattock: he has been busy with lev, but on the MSI front probably not
(12:44:52) mattock: that said, we don't _need_ to make MSI a blocker - there's 
no reason we can't push MSI installers out after the initial release... but 
that would mean living with NSIS for the 2.5 lifetime, which is not nice
(12:45:41) syzzer: hi :)
(12:45:49) cron2: when we have everything else and MSI is not

Re: [Openvpn-devel] [PATCH] tun.c: uncrustify

[Openvpn-devel] [PATCH applied] Re: Fix linking issues on MinGW

Re: [Openvpn-devel] [PATCH] tun.c: refactor driver detection and make it case-insensitive

Re: [Openvpn-devel] [PATCH] wintun: upgrade error message in case of ring registration failure

Re: [Openvpn-devel] [PATCH] wintun: check for conflicting options

[Openvpn-devel] [PATCH] wintun: check for conflicting options

[Openvpn-devel] [PATCH] wintun: upgrade error message in case of ring registration failure

[Openvpn-devel] [PATCH] tun.c: uncrustify

[Openvpn-devel] [PATCH] tun.c: refactor driver detection and make it case-insensitive

Re: [Openvpn-devel] Fwd: [PATCH 2/2] Fix linking issues on MinGW

Re: [Openvpn-devel] [PATCH 1/2] Skip DNS address validation

Re: [Openvpn-devel] Fwd: [PATCH 2/2] Fix linking issues on MinGW

[Openvpn-devel] Fwd: [PATCH 2/2] Fix linking issues on MinGW

Re: [Openvpn-devel] [PATCH 1/2] Skip DNS address validation

Re: [Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW

Re: [Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW

Re: [Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW

[Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW

[Openvpn-devel] [PATCH 1/2] Skip DNS address validation

[Openvpn-devel] [PATCH 0/2] Couple of fixes

[Openvpn-devel] Summary of the community meeting (5th February 2020)

21 matches

Site Navigation

Mail list logo

Footer information