Re: [Openvpn-devel] openvpnserv building under MSVC

, October 10, 2017 3:10 PM To: Simon Rozman Cc: openvpn-devel (openvpn-devel@lists.sourceforge.net) Subject: Re: [Openvpn-devel] openvpnserv building under MSVC wow. did you try to build it on App Veyor ? (I tried, no success) 2017-10-10 17:22 GMT+05:00 Simon Rozman <si...@rozman.si>

[Openvpn-devel] openvpnserv building under MSVC

files to compile using MSVC again. - Support for x64 platform was added. - All MSVC warnings were addressed and fixed. Can I deliver the patches for above? Best regards, Simon Rozman smime.p7s Description: S/MIME cryptographic signature

[Openvpn-devel] [PATCH] Uniform swprintf() across MinGW and MSVC compilers

Legacy _snwprintf() and snwprintf() functions replaced with ISO C swprintf(). Assigning _snwprintf() return value to unused variable was also removed at one occasion. --- src/openvpn/tun.c | 2 +- src/openvpnserv/interactive.c | 20 ++-- src/openvpnserv/validate.c

Re: [Openvpn-devel] openvpnserv building under MSVC

Hi, > -Original Message- > From: Илья Шипицин [mailto:chipits...@gmail.com] > Sent: Friday, October 13, 2017 10:28 AM > To: Simon Rozman > Cc: openvpn-devel (openvpn-devel@lists.sourceforge.net) > Subject: Re: [Openvpn-devel] openvpnserv building under MSVC > >

Re: [Openvpn-devel] [PATCH 01/13] snwprintf() => _snwprintf()

Hi, > From a technical point of view, it looks like a fine patch. But it is hard > for me > (as a non-Windows dev) to understand *why* this is needed. > It would be good to explain the rationale for a change so others can > understand it as quickly as possible. snwprintf() is not defined in

[Openvpn-devel] [PATCH] Simplify iphlpapi.dll API calls

Dynamically locating API function addresses at run-time using GetProcAddress() was a leftover from the early days of the interactive service development. It was required before `NTDDI_VERSION` was raised from Windows XP to Windows Vista. After NTDDI_VERSION API level was raised to NTDDI_VISTA,

Re: [Openvpn-devel] [PATCH 01/13] snwprintf() => _snwprintf()

Hi, Thank you for your feedback. Based on it, I have sent a new patch "[PATCH] Uniform snwprintf() across MinGW and MSVC compilers", that supersedes this one. Best regards, Simon From: Selva [mailto:selva.n...@gmail.com] Sent: Wednesday, October 11, 2017 4:32 PM To: Simon

Re: [Openvpn-devel] [PATCH] Uniform snwprintf() across MinGW and MSVC compilers

This is a follow-up (or better worded: a replacement) patch for "[PATCH 01/13] snwprintf() => _snwprintf()". I have taken into consideration all Selva's recommendations. Best regards, Simon > -Original Message----- > From: Simon Rozman [mailto:si...@rozman.si] > Sent

Re: [Openvpn-devel] [PATCH] Document ">PASSWORD:Auth-Token" real-time message

Hi, > Really great to see all your patches! Thanks a lot! I have a strong motivation for it, as I am planning some future changes for openvpnserv.exe. It would help me to keep in sync with official OpenVPN source base if the majority of base issues MSVC has with OpenVPN sources is resolved

Re: [Openvpn-devel] openvpnserv building under MSVC

I don't want to make too much confusion here and/or risk some or all of my work to get overlooked or rejected. Best regards, Simon From: Илья Шипицин [mailto:chipits...@gmail.com] Sent: Tuesday, October 10, 2017 3:10 PM To: Simon Rozman Cc: openvpn-devel (openvpn-devel@lists.sourceforge

[Openvpn-devel] [PATCH] Fix local #include to use quoted form

.h include files from the same folder or addressed relatively to the same folder should be #included using quoted form in MSVC. The angled form is reserved for include files from folders specified using /I path. Using angled form, MSVC fails to locate local #include file, unless current folder is

Re: [Openvpn-devel] openvpnserv building under MSVC

Hi, > > 1. Should I post all MSVC-specific file changes as a one single large > patch? (.sln/.vcxproj/.bat files, without .h/.c) > > That would be my preference. But for the existing patches (unless they are > stale), keep 'em as they are. Then, you can safely discard all my patches that

Re: [Openvpn-devel] [PATCH 05/13] Function prototypes are declared as "typedef ( *type_name)()" in MSVC.

linked Vista+ API calls would break compatibility with Windows XP. Best regards, Simon From: Selva [mailto:selva.n...@gmail.com] Sent: Wednesday, October 11, 2017 3:21 PM To: Simon Rozman Cc: openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel] [PATCH 05/13] Function prototypes

Re: [Openvpn-devel] [PATCH 01/13] snwprintf() => _snwprintf()

: Selva [mailto:selva.n...@gmail.com] Sent: Wednesday, October 11, 2017 3:20 PM To: Simon Rozman Cc: openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel] [PATCH 01/13] snwprintf() => _snwprintf() On Wed, Oct 11, 2017 at 6:06 AM, Simon Rozman <si...@rozman.si> wrote: Hi

[Openvpn-devel] [PATCH] Uniform snwprintf() across MinGW and MSVC compilers

MinGW's snwprintf() is a replacement for ISO C's swprintf() used by MSVC. MSVC also provides _snwprintf(), however using it leads to unportable code. After a discussion with Selva Nair on devel mailing list, an agreement was reached to use swprintf() for MSVC builds. This patch uniforms

Re: [Openvpn-devel] openvpnserv building under MSVC

Hi, > This sounds good. Please send patches (preferably with git-send-email, in > reasonable chunks) to the list so we can review and merge. Please rebase on > top of master. > > "Reasonable chunks" is a very subjective thing, of course :-) - in this case I'd > group the MSVC specific things

[Openvpn-devel] [PATCH v2] openvpnserv: Review MSVC down-casting warnings

Data size arithmetic was reviewed according to 64-bit MSVC complaints. The warnings were addressed by migrating to size_t, rewriting the code, or silencing the warnings by an explicit cast where appropriate. --- src/openvpnserv/automatic.c | 20

Re: [Openvpn-devel] [PATCH 12/13] Memory size arithmetic reviewed according to 64-bit MSVC complaints

Hi, > Some of these changes are of dubious value as the string lengths involved > are guaranteed to be small and there is no scope for overflow. And casting > only stops the compiler warning, not potential overflow, if any.. Exactly. Where there's no scope for an overflow and compiler is too

[Openvpn-devel] [PATCH] openvpnserv: Review MSVC down-casting warnings

Data size arithmetic was reviewed according to 64-bit MSVC complaints. The warnings were addressed by migrating to size_t, rewriting the code, or silencing the warnings by an explicit cast where appropriate. --- src/openvpnserv/automatic.c | 19 +++

[Openvpn-devel] [PATCH v5] openvpnserv: Review MSVC down-casting warnings

Data size arithmetic was reviewed according to 64-bit MSVC complaints. The warnings were addressed by migrating to size_t, rewriting the code, or silencing the warnings by an explicit cast where appropriate. --- src/openvpnserv/automatic.c | 17 ++--- src/openvpnserv/interactive.c

[Openvpn-devel] [PATCH v4] openvpnserv: Add support for multi-instances

While openvpn.exe can run multiple concurrent processes, openvpnserv.exe is usually only one single globally unique running process. This patch extends openvpnserv.exe to support multiple service instances in parallel allowing side-by-side OpenVPN installations. Alternate instances must be

Re: [Openvpn-devel] [PATCH 09/13] Signed/unsigned warnings of MSVC resolved

Hi, > On Wed, Nov 08, 2017 at 06:46:53PM +0000, Simon Rozman wrote: > > > The best time to re-factor a function would be when a a new use > > > case needs to change its semantics. Apart from the ill-chosen -err > > > as a return value, currently it returns 0 if au

Re: [Openvpn-devel] [PATCH applied] Re: openvpnserv: Add support for multi-instances

Hi, > I've done a bit of staring at the code as well, and it seems to make sense > (but > thanks to Selva for a thorough review and actually testing this :-) ). > > Given the interaction with EduVPN 2.4, and the fairly well localized changes, > I > agree to Selva's suggestion of having it in

Re: [Openvpn-devel] OpenVPN Interactive Service Branding

Hi, > > Hi Simon, > > Speaking of MSIs... we are planning on moving from NSIS to MSI due to > security issues like the one we fixed in previous release. At the moment four > (other) people who have expressed interest in taking part in the "create MSI > installers for OpenVPN" project. One of

[Openvpn-devel] [PATCH v2] openvpnserv: Add support for multi-instances

While openvpn.exe can run multiple concurrent processes, openvpnserv.exe is usually only one single globally unique running process. This patch extends openvpnserv.exe to support multiple service instances in parallel allowing side-by-side OpenVPN installations. Alternate instances must be

Re: [Openvpn-devel] [PATCH 09/13] Signed/unsigned warnings of MSVC resolved

Hi, Let me explain all proposed modifications case-by-case below... > > diff --git a/src/openvpn/block_dns.c b/src/openvpn/block_dns.c index > > d43cbcf..f88ba2c 100644 > > --- a/src/openvpn/block_dns.c > > +++ b/src/openvpn/block_dns.c > > @@ -370,7 +370,7 @@ get_interface_metric(const

Re: [Openvpn-devel] [PATCH 09/13] Signed/unsigned warnings of MSVC resolved

Hi, > > > > diff --git a/src/openvpn/block_dns.c b/src/openvpn/block_dns.c > > > > index d43cbcf..f88ba2c 100644 > > > > --- a/src/openvpn/block_dns.c > > > > +++ b/src/openvpn/block_dns.c > > > > @@ -370,7 +370,7 @@ get_interface_metric(const NET_IFINDEX index, > > > const ADDRESS_FAMILY family)

Re: [Openvpn-devel] OpenVPN Interactive Service Branding

Hi, > Named instances sounds like is a good idea. As you pointed out, Microsoft > itself uses command line parameters on service (like -i NAME for SQL server) > so that looks kosher. > > There is a problem though: multiple instances also need multiple service > names but the service name is

Re: [Openvpn-devel] OpenVPN Interactive Service Branding

Hi, > I seen your commits regarding win32 refactoring in > https://github.com/amebis/openvpn they are good can we count on you in > https://github.com/OpenVPN/openvpn-gui/issues/77 ? For the time being, I cannot promise anything about #77. To my estimate, #77 would take about a month or two of

[Openvpn-devel] [PATCH] openvpnserv: Add support for multi-instances

While openvpn.exe can run multiple concurrent processes, openvpnserv.exe is usually only one single globally unique running process. This patch extends openvpnserv.exe to support multiple service instances in parallel allowing side-by-side OpenVPN installations. Alternate instances must be

Re: [Openvpn-devel] OpenVPN Interactive Service Branding

Hi, Late but still, I would like to participate in the Hackatlon 2017. Can I still apply for a place, please? Best regards, Simon From: Илья Шипицин [mailto:chipits...@gmail.com] Sent: Thursday, November 02, 2017 10:36 AM To: Samuli Seppänen Cc: Simon Rozman; Selva Nair; openvpn-devel

Re: [Openvpn-devel] [PATCH v2] openvpnserv: Add support for multi-instances

Hi, > But then making the variable static just to keep a valid pointer beyond the > current block local looks like a kludge. For me seeing static applied to a > variable scoped to a block is just confusing and unusual style. Think of > this: if > you remove that static the code may still build

Re: [Openvpn-devel] [PATCH] openvpnserv: Add support for multi-instances

Sorry, I forgot to label it [PATCH v3]. :( Best regards, Simon > -Original Message- > From: Simon Rozman [mailto:si...@rozman.si] > Sent: Wednesday, November 08, 2017 7:42 PM > To: openvpn-devel@lists.sourceforge.net > Cc: Simon Rozman > Subject: [PATCH] openvp

Re: [Openvpn-devel] [PATCH v2] openvpnserv: Add support for multi-instances

Hi, > >  static SERVICE_STATUS_HANDLE service; -static SERVICE_STATUS status; > > +static SERVICE_STATUS status = { SERVICE_WIN32_SHARE_PROCESS }; > > While this is correct, making use of C99's designated init like > >       {.dwServiceType = SERVICE_WIN32_SHARE_PROCESS} would be better > and

Re: [Openvpn-devel] [PATCH 09/13] Signed/unsigned warnings of MSVC resolved

Hi, > The best time to re-factor a function would be when a a new use case needs > to change its semantics. Apart from the ill-chosen -err as a return value, > currently it returns 0 if automatic metric is in use, making it impossible to > use > it as a generic function to find the current

[Openvpn-devel] [PATCH] openvpnserv: Add support for multi-instances

While openvpn.exe can run multiple concurrent processes, openvpnserv.exe is usually only one single globally unique running process. This patch extends openvpnserv.exe to support multiple service instances in parallel allowing side-by-side OpenVPN installations. Alternate instances must be

Re: [Openvpn-devel] OpenVPN Interactive Service Branding

Hi, > >> > >> As you probably know, right now we produce Windows executables and > >> installers on Linux using openvpn-build: > >> > >> > >> > >> It seems that WiX which you mention would probably be our tool of > >> choice, given it is open source

Re: [Openvpn-devel] Windows builds (was: OpenVPN Interactive Service Branding)

Hi, > > Simon has achieved a great progress in building on Windows. WIX > > perfectly integrates into visual studio SLN, and than perfectly builds > > on app veyor)) no more cross builds:) > > That's great for Windows users, but to me cross compiling is a crucial > feature. > I don't care about

Re: [Openvpn-devel] [PATCH 09/13] Signed/unsigned warnings of MSVC resolved

Hi, > > Should your patch be merged, I shall rebase the "[PATCH 09/13] > Signed/unsigned warnings of MSVC resolved" to the new master and deliver > the next version. > > Yes, if you can review and ack/nak it :) You mean Gert to ack/nak it? I don't believe I have earned enough reputation to do

Re: [Openvpn-devel] [PATCH 09/13] Signed/unsigned warnings of MSVC resolved

Hi, > > The get_interface_metric() function should get a more thorough rewrite > than just a compiler warning shut-up. So the patch will probably get divided > in two - the simple signed/unsigned fixes and get_interface_metric() > redesign. > > For the latter, I had "re-invented" the

Re: [Openvpn-devel] [PATCH] Refactor get_interface_metric to return metric and auto flag separately

Hi, I have briefly reviewed this patch. If you look at each get_interface_metric() call you'll notice exactly the same repeating pattern: tap_metric_v4 = get_interface_metric(index, AF_INET, _auto); if (is_auto) { tap_metric_v4 = 0; }

Re: [Openvpn-devel] [PATCH] Refactor get_interface_metric to return metric and auto flag separately

the interface has some metric set. > > I want to use it in another patch where the actual metric is required even > if > automatic metric is in use. Makes sense now. Sorry for the delay. Acked-by: Simon Rozman <si...@rozman.si> Best regards, Simon smime.p7s Descrip

[Openvpn-devel] [PATCH v3] openvpnserv: Review MSVC down-casting warnings

Data size arithmetic was reviewed according to 64-bit MSVC complaints. The warnings were addressed by migrating to size_t, rewriting the code, or silencing the warnings by an explicit cast where appropriate. --- src/openvpnserv/automatic.c | 20

[Openvpn-devel] OpenVPN Interactive Service Branding

1. Do you think this commits are appropriate to get merged in the official OpenVPN source? (I can deliver git-send-email patches, of course.) 2. We would like to hear your expert opinion about this use-case. Any considerations, drawbacks and like? Thank you

Re: [Openvpn-devel] OpenVPN Interactive Service Branding

Hi, > Instead of a pipe name set at compile-time, I think its better to make this > customizable by the installer. That is, we could take service name from an > optional registry entry so that it may be renamed by the installation package. Honestly, to make the name of the named pipe and the

Re: [Openvpn-devel] [PATCH] Support fingerprint authentication

Hi, > What does this accomplish you can’t just basically do with —client-cert-not- > required? I am using --client-cert-not-required already. :) But that simplifies only the client half of the equation. TLS server will always need a certificate. And client will always need to verify it to

Re: [Openvpn-devel] [PATCH] Support fingerprint authentication

Hi, > > JJK, I think you are misreading this proposal. No hash is being sent > > as a part of the handshake -- its still client and server > > certificates that are exchanged and checked during handshake. The hash > > is exchanged by a separate channel (say snail mail:) in advance, and > >

Re: [Openvpn-devel] [PATCH] Support fingerprint authentication

Hi, > > Private and public key are still used. The patch stil uses > > certificates and TLS, it only replaces the check certificate of the > > peer's certificate against the CA with a hash check (certificate > > pinning if you want). > > > > So basically instead of saying that you trust all

Re: [Openvpn-devel] TAP-Windows MSI packages

driver later on, the damage has been done. This means me going back to the drawing board inventing our own MSI custom action to install the driver and hopefully update seamlessly. Best regards, Simon From: Simon Rozman Sent: Thursday, June 7, 2018 3:51 PM To: openvpn-devel (openvpn

[Openvpn-devel] TAP-Windows MSI packages

Hi! Finally, I have some MSI material to share with community. My playground is at https://github.com/rozmansi/tap-windows6. It proved a lot more work than I estimated back in Karlsruhe. The core problem was driver install and TAP interface creation within the MSI package. Well actually,

Re: [Openvpn-devel] TAP-Windows MSI packages

Hi, > After testing the MSI updating (installing newer MSI package over the > previous one), I have found out that WiX driver installation custom action > uninstalls the previous driver in RemoveExistingProducts pass, which > effectively removes all existing TAP interfaces. Though it installs the

[Openvpn-devel] tap-windows6 and AppVeyor

Hi! Given all the recent updates to tap-windows6 building process, the AppVeyor integration needs an update too. Now the Microsoft EWDK is used to build the driver, I wasn't able to find any such build environment on AppVeyor. If the EWDK licence allows us, we could put EWDK online and have the

Re: [Openvpn-devel] tap-windows6 and AppVeyor

, 2018 12:58 PM To: Simon Rozman Cc: Samuli Seppänen ; jkun...@microsoft.com; openvpn-devel Subject: Re: tap-windows6 and AppVeyor вс, 17 июн. 2018 г. в 14:49, Simon Rozman mailto:si...@rozman.si> >: Please, mind "The system cannot find the path specified." in the output log.

Re: [Openvpn-devel] OpenVPN on ARM64 Windows

Hi Jon, > What system are you using to generate MSIs? Marc (CC'd) has a patch for WIX > that adds support for generating ARM64 MSIs. I am using a WiX to make two separate MSI files (x86 and x64). This is the easy part - I had the WiX MSI package ready back at Hackatlon in an hour or so.

Re: [Openvpn-devel] tap-windows6 and AppVeyor

regards, Simon > -Original Message- > From: Jon Kunkee > Sent: Friday, June 15, 2018 7:58 PM > To: Илья Шипицин ; Samuli Seppänen > > Cc: Simon Rozman ; openvpn-devel de...@lists.sourceforge.net> > Subject: RE: tap-windows6 and AppVeyor > > Hi, > >

[Openvpn-devel] [PATCH] Document missing OpenVPN states

--- doc/management-notes.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/management-notes.txt b/doc/management-notes.txt index a9ba18a..908b981 100644 --- a/doc/management-notes.txt +++ b/doc/management-notes.txt @@ -362,6 +362,8 @@ ADD_ROUTES-- Adding routes to system.

Re: [Openvpn-devel] [PATCH 09/13] Signed/unsigned warnings of MSVC resolved

Hi, > > I have tested and am confirming MSVC is happy with the block_dns.c now. > > > > Should your patch be merged, I shall rebase the "[PATCH 09/13] > Signed/unsigned warnings of MSVC resolved" to the new master and deliver > the next version. > > I finally came around to merging the

Re: [Openvpn-devel] [PATCH] Return NULL if GetAdaptersInfo fails

l I have reviewed the program flow after each get_adapter_info_list() function call. All code to use the return value of get_adapter_info_list() indeed checks the return value for non-NULL before using it. Acked-by: Simon Rozman <si...@rozman.si> Regards, Simon smime.p7s Description: S/M

Re: [Openvpn-devel] Regarding tap-windows6 driver signatures and driver distribution

Hi, > > > Is there a chance the ARM64 changes (NDIS 6.30+build+installer) will > > > make it in? (Are we trying to get the MSI changes in for this > > > release?) > > Didn't have time to look at the MSI stuff yet, and haven't heard from others. > > Most likely this release will be "get things

[Openvpn-devel] TAP driver on Windows 2016 Server

Hi! Does anybody have some specific Windows 2016 Server release and build numbers from which on they require HLK certified driver? Or, do all Windows 2016 Server versions require HLK certified drivers from initial release on? I am adding a detection logic to pack multiple TAP drivers in a single

Re: [Openvpn-devel] TAP driver on Windows 2016 Server

Hi, > So we need either auto-detection (=best) or separate installers. I will do the > latter for starters so that my vacation is not ruined. But soon after we should > switch to the MSI-based installer with OS- auto-detection. Excellent. Awaiting binaries, so I can prepare the packages to test.

Re: [Openvpn-devel] tap-windows6 and AppVeyor

Hi, > I chose the EWDK thinking it would actually be easier for CI because it was > so > similar to the Win7 DDK, but from what you are saying I was wrong (at least > for AppVeyor). Are you interested converting buildtap.py to use > VS2017+WDK instead of the EWDK? I'm happy to do it, but I won't

[Openvpn-devel] [PATCH v2] Add Interactive Service developer documentation

The OpenVPN Interactive Service documentation from https://community.openvpn.net/openvpn/wiki/OpenVPNInteractiveService was upgraded with a description of the client-service communication flow, service registry configuration, and non-default instance installation. --- doc/Makefile.am

[Openvpn-devel] [PATCH] Add Interactive Service developer documentation

The OpenVPN Interactive Service documentation from https://community.openvpn.net/openvpn/wiki/OpenVPNInteractiveService was upgraded with a description of the client-service communication flow, service registry configuration, and non-default instance installation. ---

Re: [Openvpn-devel] [PATCH] Change quoted to angled form when #including external .h files

May I ask what the rationale is for this change? Use of angled and quoted form of #include filenames is mostly consistent across the OpenVPN source (src/openvpn) with those few exceptions fixed by this proposed patch. The rationale for this change is unification of #include sentences.

[Openvpn-devel] [PATCH v3] Add Interactive Service developer documentation

The OpenVPN Interactive Service documentation from https://community.openvpn.net/openvpn/wiki/OpenVPNInteractiveService was upgraded with a description of the client-service communication flow, service registry configuration, and non-default instance installation. --- doc/Makefile.am

[Openvpn-devel] [PATCH] Add missing (but optional) escape backslash to sed replace string

--- dev-tools/lz4-rebaser.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev-tools/lz4-rebaser.sh b/dev-tools/lz4-rebaser.sh index 03debcb..3771639 100755 --- a/dev-tools/lz4-rebaser.sh +++ b/dev-tools/lz4-rebaser.sh @@ -58,7 +58,7 @@ echo "* Porting upstream lz4.c to

[Openvpn-devel] [PATCH v2 09/13] Signed/unsigned warnings of MSVC resolved

This patch fixes the signed/unsigned comparison warnings discovered when compiling openvpnserv using MSVC. Wherever possible, it changes iterator and/or size variables to a more appropriate type, or uses type-casting when it is safe to do so. --- src/openvpnserv/automatic.c | 2 +-

[Openvpn-devel] [PATCH v4] Add Interactive Service developer documentation

The OpenVPN Interactive Service documentation from https://community.openvpn.net/openvpn/wiki/OpenVPNInteractiveService was upgraded with a description of the client-service communication flow, service registry configuration, and non-default instance installation. ---

[Openvpn-devel] [PATCH] Change quoted to angled form when #including external .h files

--- src/openvpn/comp-lz4.c | 2 +- src/openvpn/lzo.h | 8 src/openvpn/memdbg.h | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/openvpn/comp-lz4.c b/src/openvpn/comp-lz4.c index f2916bdd..f52fdbfb 100644 --- a/src/openvpn/comp-lz4.c +++

Re: [Openvpn-devel] New tap-windows6 driver (9.21.3) available for testing

> I've tested installing this driver on Windows 7 Pro (64-bit) and Windows > 2012r2 (64-bit) and I did not encounter any installation issues. > However, I do not have access to Windows 8 or Windows 10, nor to 32-bit > platforms. > > I would appreciate somebody could do additional driver

[Openvpn-devel] [PATCH v5] Add Interactive Service developer documentation

The OpenVPN Interactive Service documentation from https://community.openvpn.net/openvpn/wiki/OpenVPNInteractiveService was upgraded with a description of the client-service communication flow, service registry configuration, and non-default instance installation. --- Thank you Selva for your

[Openvpn-devel] [PATCH] Reference msvc-generate from compat to assure correct build order

Single-process builds start building compat project first and they fail, since the referenced config-msvc-version.h is not available yet. Multi- process rebuilds also tends to fail if the compat project is built faster than msvc-generate is able to produce the required output files. Adding a

[Openvpn-devel] [PATCH 1/2] msvc: Unify Unicode/MultiByte string setting across all cfg|plat

The openvpnserv.vcxproj source code is Windows API Unicode compliant with only Debug|x64 set to Unicode, while other cfg|plat pairs were set to MultiByte. --- src/openvpnserv/openvpnserv.vcxproj | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[Openvpn-devel] [PATCH 2/2] msvc: Move common project settings to reusable property sheets

The Visual Studio 2017 project files were refactored by migrating all repeating common settings into three property sheets: Debug.props, Release.props and the existing PropertySheet.props. This simplifies configuration management while providing uniformity across projects, configurations and

Re: [Openvpn-devel] [PATCH 1/2] msvc: Unify Unicode/MultiByte string setting across all cfg|plat

Hi, It would make the code cleaner, I agree. Since in MinGW/VS we only build openvpnserv with unicode I wonder if we should get rid of #if(n)def UNICODE ? smime.p7s Description: S/MIME cryptographic signature ___ Openvpn-devel mailing list

Re: [Openvpn-devel] [PATCH] Fix various compiler warnings

Hi, Congratulations! 518 left to go.  Acked-by: Simon Rozman I believe MSVC warning level 3 is a bit too high for a code that was not developed in MSVC or even with MSVC in mind. I lowered it to level 1, and about 8 of interesting warnings remained out of all the warning noise. Maybe we

[Openvpn-devel] [PATCH 4/5] Add MSI custom action for reliable Windows 10 detection

This patch introduces a `FindSystemInfo()` MSI custom action to reliably detect Windows 10. The MSI built-in properties for Windows version detection depend on bootstrapper's manifest. We could provide our own Windows 10 compatible EXE bootstrapper, but that would cover the Windows 10 detection in

[Openvpn-devel] [PATCH 3/5] Define _WIN32_WINNT=_WIN32_WINNT_VISTA in MSVC

This makes MSVC and MinGW build environments more alike. --- src/openvpnmsica/openvpnmsica.props | 1 + src/tapctl/tapctl.props | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/openvpnmsica/openvpnmsica.props b/src/openvpnmsica/openvpnmsica.props index

[Openvpn-devel] [PATCH 2/5] Prevent __stdcall name mangling of MSVC

Using `extern "C" __declspec(dllexport) __stdcall`, Win32 MSVC compiler exports the functions are as `_name@N`. Exporting functions using `/EXPORT` linker flag allows us to specify exact function name. Note: The 64-bit MSVC compiler does not exhibit `__stdcall` name- mangling. ---

[Openvpn-devel] [PATCH 1/5] Set output name to libopenvpnmsica.dll in MSVC builds too

On MinGW builds, the Libtool produces libopenvpnmsica.dll. The MSVC properties were updated to match this. --- src/openvpnmsica/openvpnmsica.props| 4 +++- src/openvpnmsica/openvpnmsica_resources.rc | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git

Re: [Openvpn-devel] [PATCH 1/5] Set output name to libopenvpnmsica.dll in MSVC builds too

Hi, > I build-tested with all of these patches using the openvpn-build VM in > Vagrant[1]. After the build libopenvpnmsica.dll and tapctl.exe show up > under tmp/installer/. So the build part is definitely working > correctly. > > How would I test that both of the above are operating as intended?

Re: [Openvpn-devel] [PATCH 4/5] Add MSI custom action for reliable Windows 10 detection

Hi, > > The post on this link is true for Windows 7 (May 6, 2009). It's 2018 > > now and MSI's property VersionNT got stuck on Windows 8 (602 if I > recall correctly). > > Quite right. I just talked to someone familiar with this here, and, as I > understand it, MSI will never offer a way to do

[Openvpn-devel] [PATCH 3/3] Make MSI custom action debug pop-up more informative

Each MSI custom action pops-up a message box in the _DEBUG version before commencing execution. This opens a time window for developer to attach debugger to the msiexec.exe process, set the breakpoints before custom action proceeds with execution. While those pop-up dialogs are targeted to a

[Openvpn-devel] [PATCH 2/3] Change C++ to C comments

--- src/openvpnmsica/openvpnmsica.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/openvpnmsica/openvpnmsica.c b/src/openvpnmsica/openvpnmsica.c index d1642d6a..99b47bf0 100644 --- a/src/openvpnmsica/openvpnmsica.c +++ b/src/openvpnmsica/openvpnmsica.c @@

[Openvpn-devel] [PATCH 1/3] Delete TAP interface before the TAP driver is uninstalled

The previous version of MSI installer did: - Execution Pass: rename the TAP interface to some temporary name - Commit/Rollback Pass: delete the TAP interface / rename the interface back to original name However, the WiX Toolset's Diffx extension to install and remove

Re: [Openvpn-devel] [PATCH 4/5] Add MSI custom action for reliable Windows 10 detection

Hi, > > It might be somewhat more convenient to add the PID to the debug > > MessageBox call, but it is probably MUCH more convenient to use the > > CustomAction debugging facility built into the MSI service itself: > > > > https://docs.microsoft.com/en-us/windows/desktop/Msi/debugging-custom- >

Re: [Openvpn-devel] [PATCH 4/5] Add MSI custom action for reliable Windows 10 detection

Hi, > This is painful to read, and I bet it was even more painful to write. I > am sorry it came to this, though it does look like it should(TM) work. I don't blame Microsoft for this mess. Version lies actually solve a lot of problems with legacy software. > From what I gather, the OS version

Re: [Openvpn-devel] [PATCH 2/5] Prevent __stdcall name mangling of MSVC

Hi Jon, > This approach keeps 'goes in DLL' next to the function itself, which I > like. If you're interested, another possible approach here is to use > .DEF files with MSVC, which can also do symbol aliasing: > https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using- > def-files >

[Openvpn-devel] MinGW to build DLL not EXE

Hi! I have almost finished integrating tapctl.exe and openvpnmsica.dll utilities for MSI packaging into the OpenVPN/openvpn repo. However, I am totally new with MinGW and would need some help. How do you tell the OpenVPN's build process to create a DLL file, not an EXE? My working copy is here:

Re: [Openvpn-devel] [PATCH] win: support for Visual Studio 2017

Hi, Now, that's more like it. Thanks for the directions. Will try it again and report. Yes, TAP driver can be build for ARM64. See: https://github.com/OpenVPN/tap-windows6/pull/57 https://github.com/OpenVPN/tap-windows6/pull/56 https://github.com/OpenVPN/tap-windows6/pull/55 Best

Re: [Openvpn-devel] [PATCH] win: support for Visual Studio 2017

Acked-by: Simon Rozman From: Lev Stipakov Sent: Sunday, September 30, 2018 7:19 AM To: Simon Rozman Cc: openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel] [PATCH] win: support for Visual Studio 2017 Hi, I was very delighted to see this contribution. However, after hours

Re: [Openvpn-devel] MinGW to build DLL not EXE

Hi, > Usually 'gcc -o file.dll -shared ...'. > What .dll are taking about, a plugin? Not an OpenVPN plugin actually. A separate standalone DLL file used in a later MSI packaging. Windows-only. I had a discussion with Samuli it would be best in a long term to have it in the OpenVPN/openvpn repo

Re: [Openvpn-devel] MinGW to build DLL not EXE

: Wednesday, October 10, 2018 5:55 PM To: Simon Rozman Cc: openvpn-devel Subject: Re: [Openvpn-devel] MinGW to build DLL not EXE HI, I have almost finished integrating tapctl.exe and openvpnmsica.dll utilities for MSI packaging into the OpenVPN/openvpn repo. However, I am totally new

Re: [Openvpn-devel] [PATCH] win: support for Visual Studio 2017

Hi, > This patch enables building openvpn with Visual Studio 2017. > > It is advised to use openvpn-build/msvs/build.bat which > also downloads and build required dependencies. I was very delighted to see this contribution. However, after hours of struggling to compile and prepare

Re: [Openvpn-devel] [PATCH applied] Re: Extend FindSystemInfo custom action to detect OpenVPNService state

Hi, > +finish_QueryServiceStatusEx:; > + > +// Service is not started. Is it set to auto-start? > +// MSDN describes the maximum buffer size for QueryServiceConfig() > to be 8kB. > +// This is small enough to fit on stack. > > .. there shouldn't be a ";" after a label, and no C++

Re: [Openvpn-devel] [PATCH applied] Re: Strip _stdcall suffixes (@nn) for 32-bit builds

Hi, > You really do not like this calling convention, do you? ;-) - learned > something new today, what "-Wl,--kill-at" does... (while the original > round of stdcall discussion was MSVC, here's the mingw variant) If I was importing this library into a C/C++ project, I wouldn't mind function

Re: [Openvpn-devel] [PATCH applied] Re: Introduce tapctl.exe utility and openvpnmsica.dll MSI CA

Hi, > (I *have* glanced over the code to see that there isn't anything that > looks "suspicious" - and of course it does not modify openvpn code, so > there is no risk for introducing remote exploits, crypto breaches, etc.) > > I found a few things I'd like to see cleaned up eventually... Thank

Re: [Openvpn-devel] [PATCH 5/5] Detect TAP interfaces with root-enumerated hardware ID

Hi, > On Tue, Oct 16, 2018 at 12:26:27PM +0200, Simon Rozman wrote: > > This patch extends the TAP interface enumerating to detect the TAP > > interfaces registered using "root\tap0901" hardware ID. Before, only > > TAP interfaces with legacy "tap0901&

Re: [Openvpn-devel] [Help required] Testing MSI installations

Hi, > Action 06:41:08: FindTAPInterfaces. Searching for TAP interfaces Action > start 06:41:08: FindTAPInterfaces. > CustomAction FindTAPInterfaces returned actual error code 1154 (note > this may not be 100% accurate if translation happened inside sandbox) > Error 1723. There is a problem with

  1   2   3   >