[Openvpn-devel] [PATCH: tap-windows6] Fix missing PRODUCT_PUBLISHER field in installer

[Jon Kunkee via Openvpn-devel]

Hi all,

While working on ARM64 tap-windows6, I came up with this quick fix for a minor 
issue recently reported via IRC.

This is also a Github PR:
https://github.com/OpenVPN/tap-windows6/pull/51

(The ARM64 work is still underway; I'll start a separate thread about its 
current state in a few hours.)

Thanks,
Jon


>From 6eee7713363947083e76dbe5cf2ebf8eaf3936df Mon Sep 17 00:00:00 2001
From: Jon Kunkee 
Date: Fri, 27 Apr 2018 12:01:07 -0700
Subject: [PATCH: tap-windows6] Fix missing PRODUCT_PUBLISHER field in
 installer

On Windows, the Product Publisher in Programs and Features is listed as
`${PRODUCT_PUBLISHER}` instead of "OpenVPN Technologies, Inc." as
reported on IRC.

This patch adds the `PRODUCT_PUBLISHER` variable to the buildtap.py
invocation of MakeNSIS. It also allows for `MakeNSIS` invocations with
spaces in them.
---
 buildtap.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/buildtap.py b/buildtap.py
index 6f506cd..9154ea7 100644
--- a/buildtap.py
+++ b/buildtap.py
@@ -328,13 +328,14 @@ class BuildTAPWindows(object):
 installer_type = "-oas"
 installer_file=os.path.join(self.top, 
'tap-windows'+installer_type+'-'+kv['PRODUCT_VERSION']+'-I'+kv['PRODUCT_TAP_WIN_BUILD']+'.exe')
 
-installer_cmd = "\"%s\" -DDEVCON32=%s -DDEVCON64=%s 
-DDEVCON_BASENAME=%s -DPRODUCT_TAP_WIN_COMPONENT_ID=%s -DPRODUCT_NAME=%s 
-DPRODUCT_VERSION=%s -DPRODUCT_TAP_WIN_BUILD=%s -DOUTPUT=%s -DIMAGE=%s %s" % \
+installer_cmd = "\"\"%s\" -DDEVCON32=%s -DDEVCON64=%s 
-DDEVCON_BASENAME=%s -DPRODUCT_TAP_WIN_COMPONENT_ID=%s -DPRODUCT_NAME=%s 
-DPRODUCT_PUBLISHER=\"%s\" -DPRODUCT_VERSION=%s -DPRODUCT_TAP_WIN_BUILD=%s 
-DOUTPUT=%s -DIMAGE=%s %s\"" % \
 (self.makensis,
  self.tifile(x64=False),
  self.tifile(x64=True),
  'tapinstall.exe',
  kv['PRODUCT_TAP_WIN_COMPONENT_ID'],
  kv['PRODUCT_NAME'],
+ kv['PRODUCT_PUBLISHER'],
  kv['PRODUCT_VERSION'],
  kv['PRODUCT_TAP_WIN_BUILD'],
  installer_file,
-- 
2.16.1.windows.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN on ARM64 Windows

[Jon Kunkee via Openvpn-devel]

Hi,

As a few of you have heard on IRC, I'm a Microsoft engineer working on the 
ARM64 version of Windows desktop, mostly on the x86 usermode emulation layers. 
One of the challenges usermode-only emulation poses is that applications 
relying on drivers don't run unless the driver is ported. There has been quite 
some interest in OpenVPN on my team and my proof of concept went well, so I am 
taking a shot at porting tap-windows6 to ARM64 and contributing the port back 
to the community.

(I'll have patches to share soon! Please bear with me.)

My proof of concept was pretty simple: Copy the source files into a VS2017 
driver project, tweak the project properties to reflect the SOURCES file, lie 
about the NDIS version, and suddenly I had a working ARM64 tap0901.sys through 
which I could ping an OpenVPN server's VPN-side IP. Not bad!

Needless to say, a lot more work is required to ship this. I've already done a 
lot of it, and I'm planning to do the rest--but I'd love help, even if just 
advice and historical perspective. 


The work splits into a few different buckets; I'm interested in your thoughts 
about my approach:

The Windows Driver Kit only supports ARM64 drivers from Windows 10 1709 
forward, so tap-windows6's build system needed to migrate to the newer SDK, 
complete with new folder names and build engine semantics. Just switching SDKs 
required no driver code changes and I expect it should still run downlevel to 
Win7, if not Vista (but I haven't yet tested anything but Win10!). BuildTap.py 
needed a moderate number of straightforward changes.

Appveyor will need to be updated to handle the environment and output changes; 
I'm happy to explain what's needed, but I have no previous experience with the 
service.

Along with the SDK changes, the build script needed many changes to add a third 
architecture (ARM64).

The installer also needed changes to support ARM64. I've written an NSIS header 
to replace x64.nsh to make this easy. (Complex NSIS scripting...um...ouch. 
Just...ouch. :)

The driver does technically need code changes, though: ARM64 Windows only 
supports NDIS >=6.30, while Windows 7 only supports NDIS <= 6.20. If I find 
that these changes are small enough, I'll simply base them on the NDIS version 
supported by the OS. If they're bigger, supporting two (or many) NDIS versions 
gets messy. I'm just starting on this now, but the NDIS maintainers made it 
sound somewhat simple for a driver that doesn't interact with hardware.

I cracked open the devcon.exe sample from the Win7 DDK and the only change I 
had to make was renaming the binary to tapinstall.exe. For the new build 
system, I pulled the latest devcon sources from
https://github.com/Microsoft/Windows-driver-samples/tree/master/setup/devcon
and built it with the new WDK, then renamed it to tapinstall.exe in 
buildtap.py. This might break the current signing pattern. I did make one 
change to support ARM64 as a build target, and it's under review:
https://github.com/Microsoft/Windows-driver-samples/pull/238
As for whether or not the Microsoft code can now be redistributed, I think the 
'clone the Microsoft repo' is a fairly easy way forward. On the other hand, the 
MS-PL isn't nearly as heavy as anything that the DDK came with:

https://raw.githubusercontent.com/Microsoft/Windows-driver-samples/master/LICENSE

As for signing, I get similar errors before and after my changes. I'm not quite 
sure what the goal is for which script section, but it does appear that the new 
build system invokes Inf2Cat itself using the test certs provided with the SDK. 
Since that doesn't cover tapinstall.exe or the installer EXE nor does it cover 
the official attestation case, it's insufficient. (I'll keep my ear to the 
ground about making this signing stuff more palatable in general.)

The x86 usermode daemon and UI work beautifully with the ARM64 driver, so 
bundling the properly-tri-arch tap-windows6 installer with the x86 usermode 
should be fine for now for the user experience. As pointed out on IRC, this is 
a big potential bottleneck since this is where the cryptography and routing are 
done, but it just works for now and I don't have the resources to add the ARM64 
Windows ABI to GCC+mingw nor do I feel a pressing need to resuscitate the old 
MSVC openvpn-build paths and then hope the community is happy supporting that 
in the future, seeing as how it's currently unsupported. 

Going forward I'll be happy to smoke-test new versions of OpenVPN on an ARM64 
device, as long as I have one available. 


Overall, I think ARM64 support only requires changes to tap-windows6 and the 
build environment, but there are a lot of little changes. I'd love to hear your 
feedback, and I'm sure I missed explaining something.

Thanks,
Jon Kunkee
 
(Shout out to kitsune1, cron2, mattock, pekster, and others who have given me 
feedback on IRC to get me this far!)


--

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

[Jon Kunkee via Openvpn-devel]

Hi,

>> Our projected deadline for the next tap-windows6 release is June 
>> 20th.

Is this still the target? 

How can I help with testing? My 'can I ping the appliance VM's VPN
address' test doesn't feel very thorough at all.

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?)

> Like "can I run HLK tests on Amazon EC2/Azure VMs?"

I've run the HCK server in a local Hyper-V VM before, so I don't see why not. 
The trick is making sure the underlying Server OS is the right version or it
won't install.

I suppose it's not well-documented because most drivers require that matching 
hardware be present, and that doesn't make sense in a VM. There is no technical 
reason the HCK/HLK clients should not work. (I briefly considered doing 
HCK/HLK validation as a side gig until I realized that the all-software case is 
fairly rare. Am I wrong? I could see offering AWS/Azure automation of 
HCK/HLK setup being valuable as a simple OSS project, even if the tests run
on local hardware connected via VPN.)

My 2c,
Jon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Jon Kunkee via Openvpn-devel]

 Hi Gert,

>>> Our projected deadline for the next tap-windows6 release is June 
>>> 20th. 
>>
>> Is this still the target? 
>
> No, we moved it to (tentatively) June 27th.  There was some sort of 
> major outage of Samuli's Infrastructure which took too much time to 
> fix. 

Ouch for Samuli.

My motivation is simple: The Microsoft partner that asked for this port
wants to know ASAP when it's released so they can tell people about it.
That said, as long as I get the final release date to them promptly
they can deal with whatever ends up happening.

Thanks for the update!

> The goal is to have the 3 ARM64 related PRs plus the version number PR 
> merged after a bit of smoketesting on other platforms

Wonderful.

Samuli, let me know if you think I can help.

> Most likely this release will be "get things out with compromises" - 

This makes sense, no worries. It's already a fairly complex release.

> Then, focus on make nicer installers - .msi for the tap driver, .msi 
> for openvpn proper, return to *one* driver that has proper signatures 
> for everything. 

I'll take a closer look at WIX support for ARM64. This timeline is easier to
work with.

Cheers,
Jon


pgpRtBzWp6IzL.pgp
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Jon Kunkee via Openvpn-devel]

As I read the license (IANAL), consumers of the EWDK can copy, 'install', and 
run 
it pretty much anywhere in support of building software for Windows, just not 
as a public download.

A 5GB download is prohibitive, but do note that 'unpacking' is as simple as 
mounting the ISO file.

-Original Message-
From: Simon Rozman  
Sent: Thursday, June 14, 2018 10:35 AM
To: chipits...@gmail.com; Jon Kunkee 
Cc: Samuli Seppänen (sam...@openvpn.net) ; openvpn-devel 
(openvpn-devel@lists.sourceforge.net) 
Subject: 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
AppVeyor download and unpack it before build. Although portable, the EWDK is
5GB making this option far from ideal.

Or, we could politely ask AppVeyor to introduce an EWDK building
environment. :)

Does anybody have any idea how to address this challenge?

Best regards,
Simon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Jon Kunkee via Openvpn-devel]

Hi,

I like the idea of asking AppVeyor if they could include the EWDK in one of 
their images. It is a standalone tool, so Visual Studio is not needed.

Sadly I don't see a Chocolatey package for the EWDK. That would have been 
convenient.

The AppVeyor docs[1] say that the Visual Studio 2017 image in AppVeyor already 
has the Windows Driver Kit (WDK) installed. Buildtap.py would need a couple of 
changes to consume the WDK instead of the EWDK, but it is an option.

Thanks,
Jon

[1] https://www.appveyor.com/docs/build-environment/

From: Илья Шипицин  
Sent: Friday, June 15, 2018 12:14 AM
To: Samuli Seppänen 
Cc: Jon Kunkee ; Simon Rozman ; 
openvpn-devel 
Subject: Re: tap-windows6 and AppVeyor

hi,

I have some very amazing expirience with app veyor when I was playing with 
mingw builds.
there was an issue related to mingw and I saw it between builds (mingw 
upgraded), so I first decided "could it be app veyor ?!"

people from app veyor were very helpful in troubleshooting that.


so, I guess we can try to open an issue in their tracker this time as well.


as for network share - due to "wanna cry" and similar malwares, network shares 
are blocked over internet usually.
another option might be to try build services at 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvisualstudio.com=02%7C01%7Cjkunkee%40microsoft.com%7C9ca0701aa3a948090f8208d5d28fa5b7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636646436767357213=virhpLwaa%2Fbdff2JpVzdNYGP5yLckjpUIp4I%2BQeuH4I%3D=0

пт, 15 июн. 2018 г. в 11:28, Samuli Seppänen :
Perhaps we could make the ISO available as a network share?

Il 14/06/2018 23:43, Jon Kunkee ha scritto:
> As I read the license (IANAL), consumers of the EWDK can copy, 'install', and 
> run 
> it pretty much anywhere in support of building software for Windows, just not 
> as a public download.
> 
> A 5GB download is prohibitive, but do note that 'unpacking' is as simple as 
> mounting the ISO file.
> 
> -Original Message-
> From: Simon Rozman  
> Sent: Thursday, June 14, 2018 10:35 AM
> To: mailto:chipits...@gmail.com; Jon Kunkee 
> Cc: Samuli Seppänen (mailto:sam...@openvpn.net) ; 
> openvpn-devel (mailto:openvpn-devel@lists.sourceforge.net) 
> 
> Subject: 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
> AppVeyor download and unpack it before build. Although portable, the EWDK is
> 5GB making this option far from ideal.
> 
> Or, we could politely ask AppVeyor to introduce an EWDK building
> environment. :)
> 
> Does anybody have any idea how to address this challenge?
> 
> Best regards,
> Simon
> 


-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Jon Kunkee via Openvpn-devel]

>> Our test environment currently has the following nodes: 
>> 
>> - One combined HLK Studio/controller 
>> - Four identical HLK client nodes 
>> - OpenVPN test server 
>> 
>> The HLK nodes are all Windows Server 2016 as that is our primary target. 
>> The OpenVPN test server provides the HLK clients with an IPv6 address 
>> and IPv6 gateway - this is required for almost all "Run" tests. All of 
>> the nodes are in Amazon EC2. With the above setup 54 tests pass and 9 fail. 

This sounds great.

>> The "Support machine" you mentioned is still missing. I will try to set 
>> it up today and check how many of the currently failing tests start passing. 

If the failures look network-topology-related, this should be the missing link.
The "support machine" should be a second host on the VPN that the HLK server can
talk to for generating traffic.

If I get access to the HLK machine I'll be inspecting the detailed errors
reported by the failing tests.

> I looked at "LAN Testing Prerequisites" in HLK documentation and it not 
> entirely clear what is needed: 
>
> https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/lan-testing-prerequisites
>  
>
> The document hints thats we would need to have at least one real 
> physical HLK client with 4 or 8 cores. It is also mentioned that Windows 
> Server Core is needed as well. 
>
> Anyways, some of these things may not be applicable to us. I guess the 
> best we can do is go through the test failures individually and see what 
> is happening. 

Guesswork sucks. :( Maybe I can help a little...

Windows Server 2016 has two installation modes: Core and Desktop Experience.
From what I've read, it just needs to be in Core mode for the test and either
kind of installation can be switched to the other.

The core and RAM requirements should be acheivable in EC2. Hardware is only
required if the driver exposes a hardware feature like Receive-Side Scaling that
relates to processor groupings.

> One thing to look at is HLK filters. Maybe they can be applied to 
> prevent inapplicable tests from being run. 
>
> I'm also not sure if passing the all tests entitles us to code 
> signatures from Microsoft or not. It could be that HLK tests pass, but 
> the test setup is not valid from signing viewpoint (e.g. not having a 
> physical 4-8 core server as a HLK client). 

This is described in the WHCP Guidelines doc linked from the prereqs page:

http://go.microsoft.com/fwlink/p/?LinkID=615222 (heads-up: Word doc)

If I'm reading this right, the HLK should automatically select all the right
tests for the driver. It'll be informative to see what it decides on.

VM-based testing is allowed for para-virtualization drivers, which tap-windows6
might qualify as. Apparently there is an Issue Resolution process that is used
to officially qualify a driver for this classification.

>> Note that right now I'm running the tests against tap-windows-9.22.1 to 
>> give us a baseline. That way we can check if our recent updates have 
>> broken (or possibly fixed) something. With 4 HLK clients the runtime of 
>> the whole test suite is almost reasonable. With one node it took 10+ hours. 

The idea of a baseline is great. Let's avoid breaking things. :)

>> I can definitely grant you access to the HLK controller so that you can 
>> check what is happening. If you're working today around 16:00-18:00 UTC 
>> please poke me at #openvpn-devel and we'll get you started. 

Sorry I wasn't available this round; I'll be available tomorrow 16:00-18:00 UTC
unless I hear otherwise from you.


So:
 * Please start a conversation with the certification team through the signing
   website. They will know for sure which tests are needed and what category of
   driver tap-windows6 is classified as.
 * I'll be online during the suggested window in ~22 hours so we can try and
   resolve the existing test failures. This way we'll be ready with passing
   tests whatever the classification comes in as. :)

Jon


pgpCncx7U8g4E.pgp
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Jon Kunkee via Openvpn-devel]

> Testing the signatures and the driver on ARM64 would be good. We don't 
> have any ARM64 Windows hardware at our disposal. 

Drop me a package and I'll take it for a spin. I have at least one device
with Secure Boot set up on a released build (1803).

> We don't have any tap-windows6 -specific tests at the moment, so I 
> generally just run the OpenVPN test suite against a bunch of OpenVPN 2.x 
> / Access Server / Private Tunnel servers: 
>  

I can give that a shot. If I can't figure something out from the README,
I'll ask questions here.

> Given that tap-windows6 driver has seen lots of modifications having 
> more focused tests would be good. Any ideas what we should test and how? 

As for tap-windows6, I have to profess a merely general understanding of
what it does: It allows the usermode daemon to read, intercept, and emit
raw network traffic, while the firewalling, routing, and encryption are
done by the OpenVPN daemon after the traffic leaves the driver.

Given that, I can think of a few test cases (not ordered in any way):

(All tests should run under Driver Verifier with basic sanity and NDIS
checks enabled.)

 * Heavy load on multiple TAPs
 * Upgrade
 * Empty, small, ~MTU, >MTU, and Jumbo packets
 * API fuzzing
 * Power transition testing

...but all of these take varying levels of dev investment to automate.

The easiest next step would be to expand the ping test to try varying
packet sizes (-l). (Windows' ping doesn't have a 'flood' option...)

My 2c,
Jon


pgpOcqUOVOlMd.pgp
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Jon Kunkee via Openvpn-devel]

 
Hi,

> as a quick note - sorry, we won't make "June 27" as release date for 
> the new tap driver.

> We tentatively plan for "one more week" now, which would be July 4th. 

No worries. Thanks for the update!

>  The Windows HLK tests for Server 2016 are somewhat 
> "demanding" from what I hear from Samuli (you need to have a larger 
> setup than "just the machine with the driver", it actually wants to 
> talk through the driver to "things" - which need to be provisioned, 
> etc.). 

> Jon, do you have experience with the HLK test suite and could help 
> explain some of the test failures ("what does the system expect to 
> find here?") - what's remaining does not seem to be "driver" related 
> but "things the tests expect to see in the network behind that driver"... 
> gert 

I have experience running the PCI portion of the HLK from Windows 8, so
that gives me the basic idea. Those tests required two machines: the
one with the device and the driver and the one with the HLK server.

Network device testing is more complex because the test needs to control
both the OS' end of the traffic and the external traffic. I found this:

https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/lan-testing-prerequisites
(apologies if Exchange or Outlook mangles that link... ):

It appears that you need three devices: the HLK server, the device with
the 'hardware' and the driver for testing ('Test Machine' with a 'message
device'), and the external traffic source/sink ('Support Machine'). All
three probably need a backchannel link to the HLK server, while the Test
Machine and Support Machine do best with a dedicated link through the
device whose driver is being tested.

There should be a predefined set of individual tests that are required
by the signature service, probably NDISTest 6.5.

I'd be happy to review failure logs to help figure out what's going wrong.

Cheers,
Jon


pgpAnBIuyxqSB.pgp
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN on ARM64 Windows

[Jon Kunkee via Openvpn-devel]

Hi Simon,

What system are you using to generate MSIs? Marc (CC'd) has a
patch for WIX that adds support for generating ARM64 MSIs.

Are you wrapping two arch-specific MSIs in an EXE, or doing one
mixed MSI? Two MSIs will be very simple to add ARM64 to, while
one mixed MSI will be harder.

As for tapinstall, a standalone tapinstall under VS2017 will work
perfectly with what I'm building since the EWDK consumes the
vcxproj and sln files directly.

In other news, I should have a groundwork/cleanup PR ready today! 

Thanks,
Jon

-Original Message-
From: Simon Rozman  
Sent: 05/02/2018 9:36 AM
To: Samuli Seppänen ; Jon Kunkee ; 
openvpn-devel@lists.sourceforge.net
Cc: Marc Sweetgall 
Subject: RE: [Openvpn-devel] OpenVPN on ARM64 Windows

Hi,

> We intend to switch away from NSIS to MSI packages. I believe Simon
> already did some work in there but he was rather busy for an extended
> period of time. But now he is back, so migrating away from NSIS might make
> sense at this point. Thoughts Simon?

I have already started working on it. I am writing a tapinstall.exe utility
from scratch. I am using Visual Studio 2017 for building, so this is pretty
much inline with what Jon is using. Otherwise, the utility will be quite
simple to build using a Makefile approach too, so it could use existing TAP
driver build system as well.

Regards,
Simon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN on ARM64 Windows

[Jon Kunkee via Openvpn-devel]

First, apologies to all those using PINE and similar. Outlook doesn't know what
linebreaks or columns are, so I'm stuck compensating with Notepad++. :/


>From: Samuli Seppänen  
>Sent: 04/29/2018 5:27 AM
>
>Hi and welcome!

Thank you!


>> Appveyor will need to be updated to handle the environment and output 
>> changes;
>> I'm happy to explain what's needed, but I have no previous experience with 
>> the
>> service.
>
>Ilya may be able to help you with that: he has written all our AppVeyor
>integrations so far.

I'm tweaking my changes so setting up the build environment is a matter of
mounting the WDK ISO and tweaking paths.py. Hopefully that helps.


>I'm very interested in seeing and testing these changes. I think porting
>the buildsystem to a newer SDK would be a good candidate for a PR.

>> Along with the SDK changes, the build script needed many changes to add a
>> third architecture (ARM64).
>
>These changes would make another PR.

>One final note on PRs/patches: keep them as small and atomic as possible
>and they will be easy to review and marge. Just like you did with your
>first PR :).

I think I see a pattern here, and I like it. :)

This PR contains several simple commits:
https://github.com/OpenVPN/tap-windows6/pull/52

Would that be better as several PRs (except the two commits that overlap)?

With this groundwork laid, here's my PR plan:
 * change the build system version
 * move to a newer NDIS version
 * build for ARM64
 * pack ARM64 in the installer

Each of these would be a sequence of fairly small, concise commits to aid 
review.

Thanks,
Jon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Jon Kunkee via Openvpn-devel]

Agreed. I leapt a bit too far to land at my conclusion. :| I gladly defer to 
those who have to live with this decision in the long run.

(Unfortunately, it seems that MS' VSTS doesn't have any WDK or EWDK CI 
solutions at all...oh well.)

-Original Message-
From: Simon Rozman  
Sent: Tuesday, July 3, 2018 12:40 PM
To: Jon Kunkee ; Илья Шипицин ; 
Samuli Seppänen 
Cc: openvpn-devel 
Subject: RE: 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 get to it
> until next week at the earliest...

EWDK is a nice step forward in simplifying the build environment.
Unfortunately, a step too forward in AppVeyor's case. ;)

The decision to keep EWDK, revert back to VS2017+WDK, or support both is
probably best to be made by other team members working on TAP driver most.

Best regards,
Simon
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Upstreaming pqcrypto changes from microsoft/openvpn

[Jon Kunkee via Openvpn-devel]

Hi,

(Retitling thread from RE: [Openvpn-devel] Topics for the community meeting 
(Wed, 13th June 2018))

> do you know this activity https://github.com/Microsoft/openvpn/ ?
> there are interesting things

There are *very* interesting things there!

> Do you know if Kevin (or his manager/team) plans to push his work upstream 
> (i.e. to us) at some point?

Samuli and Илья, I'd like to introduce you to Kevin Kane. He is the current 
maintainer of the Microsoft\openvpn pqcrypto branch on Github.

He is working on developing encryption standards that are resistant to 
quantum-mechanics-based attacks. This includes taking existing products and 
adding experimental implementations of the experimental standards to 
them—including OpenVPN and OpenSSL. Over time these new techniques will be 
studied, refined, tested, and otherwise hammered on in the furnace of 
open-source cryptography until they gain some measure of trust.

Both the experimental and untested nature of his work mean that no, his code 
isn’t ready to be merged into OpenVPN/master…yet!

In the meantime, he would love to work with someone from the OpenVPN 
community—or even the organization itself—to make the connection official and 
to refine his additions. Some of the needed refinement requires familiarity 
with the overall build system, while a forward-looking cryptographer or 
protocol guru might take interest in what's developing under the hood.

I don't know much about the current status of the project, but Kevin is happy 
to answer questions and would love to hear from you.

Thanks,
Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Topics for the community meeting (Wed, 13th June 2018)

[Jon Kunkee via Openvpn-devel]

I don't know right off, but I will ask. 

-Original Message-
From: Samuli Seppänen  
Sent: Tuesday, July 3, 2018 11:23 AM
To: Jon Kunkee ; Илья Шипицин 
Cc: openvpn-devel 
Subject: Re: [Openvpn-devel] Topics for the community meeting (Wed, 13th June 
2018)

Hi Jon,

Do you know if Kevin (or his manager/team) plans to push his work
upstream (i.e. to us) at some point?

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock


Il 03/07/2018 20:55, Jon Kunkee ha scritto:
> Yes, I am aware of that. Note that it’s not tap-windows6, but openvpn.
> 
>  
> 
> I talked to the primary contributor to that fork, Kevin Kane, a few days
> ago. When I asked if his team had done anything with signing the driver
> or doing the HLK work, he said his team uses tap-windows6 as-shipped,
> complete with signatures. His work is on the usermode daemon’s crypto
> engine, if I understood the commit messages right, so any changes he
> makes aren’t related to the driver.
> 
>  
> 
> *From:* Илья Шипицин 
> *Sent:* Tuesday, July 3, 2018 10:50 AM
> *To:* Jon Kunkee 
> *Cc:* Samuli Seppänen ; openvpn-devel
> 
> *Subject:* Re: [Openvpn-devel] Topics for the community meeting (Wed,
> 13th June 2018)
> 
>  
> 
> Hello, Jon.
> 
>  
> 
> do you know this activity 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fopenvpn%2Fdata=02%7C01%7Cjkunkee%40microsoft.com%7Cbd8e7cd00b2e4b35d04208d5e111f8df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662389663864307sdata=v%2Frbq%2F%2BJKjIbZTlgzrlIfMbfsHsM6raJFOBzdJlSs%2Fo%3Dreserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fopenvpn%2Fdata=02%7C01%7Cjkunkee%40microsoft.com%7Cbd8e7cd00b2e4b35d04208d5e111f8df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662389663864307sdata=v%2Frbq%2F%2BJKjIbZTlgzrlIfMbfsHsM6raJFOBzdJlSs%2Fo%3Dreserved=0>
> ?
> 
> there are interesting things
> 
>  
> 
> вт, 3 июл. 2018 г. в 22:43, Jon Kunkee via Openvpn-devel
>  <mailto:openvpn-devel@lists.sourceforge.net>>:
> 
> Hi,
> 
> 2. Tap-windows6 patches, building and testing
> 
> In order to get the tap-windows6 driver signed properly for Windows
> Server 2016, it needs to pass the Windows Hardware Certification
> Program subset of the Windows Hardware Logo Kit (HLK) tests. Samuli
> has the tests running in EC2, but there are some failures.
> 
> Some of the failures are basically paperwork, like the Static
> Verification logs test. Some reflect needed tweaks in the
> environment, like the Running on Server Core test. Others reflect
> possible code bugs, and since I have significant experience doing
> Windows kernel debugging I'm investigating those.
> 
> I spent yesterday setting up a local HLK-based test environment with
> kernel debugging. Today I'm trying to get two OpenVPN clients to be
> able to talk to each other over a VPN so I can start reproducing and
> investigating the failures. (I will be sending a mail to
> openvpn-users asking for help since it would be quite noisy to
> explain  on IRC.)
> 
> Cheers,
> Jon Kunkee
> Software Developer
> Microsoft
> 
> -Original Message-
> From: Samuli Seppänen mailto:sam...@openvpn.net>>
> Sent: Tuesday, July 3, 2018 10:30 AM
> To: openvpn-devel@lists.sourceforge.net
> <mailto:openvpn-devel@lists.sourceforge.net>
> Subject: [Openvpn-devel] Topics for the community meeting (Wed, 13th
> June 2018)
> 
> Hi,
> 
> We're going to have an IRC meeting starting at 11:30 CET
> (9:30 UTC) on #openvpn-meeting  irc.freenode.net
> 
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Firc.freenode.netdata=02%7C01%7Cjkunkee%40microsoft.com%7Cbd8e7cd00b2e4b35d04208d5e111f8df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662389663864307sdata=08TNQA7wZFTY3OXQbxn7V67qXbg9xCyGeA6dGzsNGSg%3Dreserved=0>.
> You do not have to be logged in to Freenode to join the channel.
> 
> Current topic list along with basic information is here:
> 
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.openvpn.net%2Fopenvpn%2Fwiki%2FTopics-2018-06-13data=02%7C01%7Cjkunkee%40microsoft.com%7Cbd8e7cd00b2e4b35d04208d5e111f8df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662389663864307sdata=UoPqviNEki3Um1pWPIq8WM7m3QlExHAsjlllwGCc3Lk%3Dreserved=0
> 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.openvpn.net%2Fopenvpn%2Fwiki%2FTopics-2018-06-13data=02%7C01%7Cjkunkee%40microsoft.com%7Cbd8e7cd00b2e4b35d04208d5e111f8df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%

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

[Jon Kunkee via Openvpn-devel]

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 get to it until next week at the 
earliest...

-Original Message-
From: Simon Rozman  
Sent: Tuesday, July 3, 2018 6:45 AM
To: Jon Kunkee ; Илья Шипицин ; 
Samuli Seppänen 
Cc: openvpn-devel 
Subject: RE: tap-windows6 and AppVeyor

Hi,

I was dismissed by the AppVeyor about an image preinstalled with EWDK request. 
They explained I can use their build cache to maintain a local EWDK copy.
Unfortunately, the build cache is account-specific, meaning every user trying 
to run its own fork (including OpenVPN for upstream) will require AppVeyor 
Premium plan. EWDK won't fit into 1GB build cache limit with Free/Basic plan.

So, we still have Jon's alternative proposal to support EWDK *and* VS2015+WDK 
building in buildtap.py.
The downside to this approach is, we are using slightly different build 
environment for CI.
 
Best 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,
> 
> I like the idea of asking AppVeyor if they could include the EWDK in one of
> their images. It is a standalone tool, so Visual Studio is not needed.
> 
> Sadly I don't see a Chocolatey package for the EWDK. That would have been
> convenient.
> 
> The AppVeyor docs[1] say that the Visual Studio 2017 image in AppVeyor
> already has the Windows Driver Kit (WDK) installed. Buildtap.py would need
> a couple of changes to consume the WDK instead of the EWDK, but it is an
> option.
> 
> Thanks,
> Jon
> 
> [1] https://www.appveyor.com/docs/build-environment/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Topics for the community meeting (Wed, 13th June 2018)

[Jon Kunkee via Openvpn-devel]

Hi,

2. Tap-windows6 patches, building and testing

In order to get the tap-windows6 driver signed properly for Windows Server 
2016, it needs to pass the Windows Hardware Certification Program subset of the 
Windows Hardware Logo Kit (HLK) tests. Samuli has the tests running in EC2, but 
there are some failures.

Some of the failures are basically paperwork, like the Static Verification logs 
test. Some reflect needed tweaks in the environment, like the Running on Server 
Core test. Others reflect possible code bugs, and since I have significant 
experience doing Windows kernel debugging I'm investigating those.

I spent yesterday setting up a local HLK-based test environment with kernel 
debugging. Today I'm trying to get two OpenVPN clients to be able to talk to 
each other over a VPN so I can start reproducing and investigating the 
failures. (I will be sending a mail to openvpn-users asking for help since it 
would be quite noisy to explain  on IRC.)

Cheers,
Jon Kunkee
Software Developer
Microsoft

-Original Message-
From: Samuli Seppänen  
Sent: Tuesday, July 3, 2018 10:30 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [Openvpn-devel] Topics for the community meeting (Wed, 13th June 2018)

Hi,

We're going to have an IRC meeting starting at 11:30 CET
(9:30 UTC) on #openvpn-meeting  irc.freenode.net. You do not have to be 
logged in to Freenode to join the channel.

Current topic list along with basic information is here:



If you have any other things you'd like to bring up, respond to this mail, send 
me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments on the 
topics by responding to this email or to the summary email sent after the 
meeting. Whenever possible, we'll also respond to existing, related email 
threads.

--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Topics for the community meeting (Wed, 13th June 2018)

[Jon Kunkee via Openvpn-devel]

Yes, I am aware of that. Note that it’s not tap-windows6, but openvpn.

I talked to the primary contributor to that fork, Kevin Kane, a few days ago. 
When I asked if his team had done anything with signing the driver or doing the 
HLK work, he said his team uses tap-windows6 as-shipped, complete with 
signatures. His work is on the usermode daemon’s crypto engine, if I understood 
the commit messages right, so any changes he makes aren’t related to the driver.

From: Илья Шипицин 
Sent: Tuesday, July 3, 2018 10:50 AM
To: Jon Kunkee 
Cc: Samuli Seppänen ; openvpn-devel 

Subject: Re: [Openvpn-devel] Topics for the community meeting (Wed, 13th June 
2018)

Hello, Jon.

do you know this activity 
https://github.com/Microsoft/openvpn/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fopenvpn%2F=02%7C01%7Cjkunkee%40microsoft.com%7Cd379e0c4e8c949d3d5f408d5e10d61e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662369998711232=%2FrYPhxiAOCTYikpq3uIV1X3VUTR%2Fn2bz5G%2Fu9TA11vI%3D=0>
 ?
there are interesting things

вт, 3 июл. 2018 г. в 22:43, Jon Kunkee via Openvpn-devel 
mailto:openvpn-devel@lists.sourceforge.net>>:
Hi,

2. Tap-windows6 patches, building and testing

In order to get the tap-windows6 driver signed properly for Windows Server 
2016, it needs to pass the Windows Hardware Certification Program subset of the 
Windows Hardware Logo Kit (HLK) tests. Samuli has the tests running in EC2, but 
there are some failures.

Some of the failures are basically paperwork, like the Static Verification logs 
test. Some reflect needed tweaks in the environment, like the Running on Server 
Core test. Others reflect possible code bugs, and since I have significant 
experience doing Windows kernel debugging I'm investigating those.

I spent yesterday setting up a local HLK-based test environment with kernel 
debugging. Today I'm trying to get two OpenVPN clients to be able to talk to 
each other over a VPN so I can start reproducing and investigating the 
failures. (I will be sending a mail to openvpn-users asking for help since it 
would be quite noisy to explain  on IRC.)

Cheers,
Jon Kunkee
Software Developer
Microsoft

-Original Message-
From: Samuli Seppänen mailto:sam...@openvpn.net>>
Sent: Tuesday, July 3, 2018 10:30 AM
To: 
openvpn-devel@lists.sourceforge.net<mailto:openvpn-devel@lists.sourceforge.net>
Subject: [Openvpn-devel] Topics for the community meeting (Wed, 13th June 2018)

Hi,

We're going to have an IRC meeting starting at 11:30 CET
(9:30 UTC) on #openvpn-meeting  
irc.freenode.net<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Firc.freenode.net=02%7C01%7Cjkunkee%40microsoft.com%7Cd379e0c4e8c949d3d5f408d5e10d61e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662369998721242=LnnttQ15YIIZw4RlJayIaohhI31So32ha0s7WFp1HnA%3D=0>.
 You do not have to be logged in to Freenode to join the channel.

Current topic list along with basic information is here:

<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.openvpn.net%2Fopenvpn%2Fwiki%2FTopics-2018-06-13data=02%7C01%7Cjkunkee%40microsoft.com%7C2ff5949944a34864919b08d5e10aa0b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662358125323471sdata=E2tnMk95DPL%2BFpUNM8td0lQd0PTMmfZ8ZAXUsGBES%2FA%3Dreserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.openvpn.net%2Fopenvpn%2Fwiki%2FTopics-2018-06-13=02%7C01%7Cjkunkee%40microsoft.com%7Cd379e0c4e8c949d3d5f408d5e10d61e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662369998721242=GpumX24oaDchDyBWaT%2FfX%2BNUYrBdVqNO3xWy3C44IGc%3D=0>>

If you have any other things you'd like to bring up, respond to this mail, send 
me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments on the 
topics by responding to this email or to the summary email sent after the 
meeting. Whenever possible, we'll also respond to existing, related email 
threads.

--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsdm.link%2Fslashdot=02%7C01%7Cjkunkee%40microsoft.com%7Cd379e0c4e8c949d3d5f408d5e10d61e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662369998731251=fGrHkwJMZ8ML170y94azaNJ1udr1q02JJdjyQkWyt5Y%3D=0>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net<mailto:Openvpn-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/openvpn-devel<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fopenvpn-devel=02%7C01%7Cjkunkee%40microsoft.com%7Cd379e0c4e8c949d3d5

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

[Jon Kunkee via Openvpn-devel]

>> From what I gather, the OS version should be checked in the
>> CustomAction's MSI execution conditions instead of in the CustomAction
>> itself. The appropriate information can then be passed in based on that:
>> 
>> https://blogs.msdn.microsoft.com/cjacks/2009/05/06/why-custom-actions-
>> get-a-windows-vista-version-lie-on-windows-7/

> 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 this Right on Windows 10. I'm not sure 
what 
the general messaging is from Microsoft around MSI, but my personal 
perception is that it is not moving forward anymore.

> I am open to suggestions, how to make a "regular/attestation signed/WHQL"
> selection logic in the MSI. MSI packages have up to three driver flavours
> packed and only one must be installed:
> - x86 MSI has regular+attestation signed
> - x64 has regular+attestation+WHQL
> - ARM64 will have attestation signed only

Fortunately, I *do* have a suggestion here...I think.

First, though, let's make sure I'm thinking straight: In your new system, there 
is an EXE that runs, detects the architecture, unpacks the right MSI, and runs 
the right MSI, right?

*If* I have that right, the EXE could be manifested as Windows-10-aware:

Manifest contents:
https://docs.microsoft.com/en-us/windows/desktop/SysInfo/targeting-your-application-at-windows-8-1
VS workflow:
https://docs.microsoft.com/en-us/cpp/build/how-to-embed-a-manifest-inside-a-c-cpp-application

Basically, you write an XML file and pack it in the EXE as a resource. Visual 
Studio will do this for you if the file is in your VS project source file list. 
I'm 
not sure how you'd do this with mingw_w64, but you'd probably invoke the 
equivalent of mt.exe:

https://stackoverflow.com/questions/1423492/how-do-i-add-a-manifest-to-an-executable-using-mt-exe

The parent installer could then call GetVersionEx without being lied to and 
pass it in to your CustomAction DLL through msiexec:

https://www.codeproject.com/articles/16767/how-to-pass-command-line-arguments-to-msi-installe

Let me know if that doesn't make sense or won't work for what you're doing.

Thanks,
Jon



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

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

[Jon Kunkee via Openvpn-devel]

LGTM, Samuli.

-Original Message-
From: Simon Rozman  
Sent: Tuesday, October 16, 2018 3:26 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [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 fa408296..074635d0 100644
--- a/src/openvpnmsica/openvpnmsica.props
+++ b/src/openvpnmsica/openvpnmsica.props
@@ -8,6 +8,7 @@
   
 
   
..\compat;$(TAP_WINDOWS_HOME)/include;%(AdditionalIncludeDirectories)
+  
_WIN32_WINNT=_WIN32_WINNT_VISTA;%(PreprocessorDefinitions)
 
 
   Windows
diff --git a/src/tapctl/tapctl.props b/src/tapctl/tapctl.props
index 152954ed..0257b9ff 100644
--- a/src/tapctl/tapctl.props
+++ b/src/tapctl/tapctl.props
@@ -7,7 +7,7 @@
   
   
 
-  
_CONSOLE;%(PreprocessorDefinitions)
+  
_CONSOLE;_WIN32_WINNT=_WIN32_WINNT_VISTA;%(PreprocessorDefinitions)
   
..\compat;$(TAP_WINDOWS_HOME)/include;%(AdditionalIncludeDirectories)
 
 
-- 
2.19.0.windows.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fopenvpn-develdata=02%7C01%7Cjkunkee%40microsoft.com%7Cd4c1e876c17c480297d208d63351eb3e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752824279734760sdata=VNabZb0XFntX44P8XdBZdXbEkFUTr3md02hzQ%2Bto0Yo%3Dreserved=0


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

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

[Jon Kunkee via Openvpn-devel]

This looks pretty straightforward to me.

-Original Message-
From: Simon Rozman  
Sent: Tuesday, October 16, 2018 3:26 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [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 a/src/openvpnmsica/openvpnmsica.props 
b/src/openvpnmsica/openvpnmsica.props
index 0e31bc4f..fa408296 100644
--- a/src/openvpnmsica/openvpnmsica.props
+++ b/src/openvpnmsica/openvpnmsica.props
@@ -2,7 +2,9 @@
 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschemas.microsoft.com%2Fdeveloper%2Fmsbuild%2F2003data=02%7C01%7Cjkunkee%40microsoft.com%7C6dd3259ae2044b779b9a08d63351edc6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752824311161400sdata=grtBK2tQpY7ZYBNWI%2FaHTJj7RP8JHQ0v%2BaoX1YwLi6o%3Dreserved=0;>
   
   
-  
+  
+lib$(ProjectName)
+  
   
 
   
..\compat;$(TAP_WINDOWS_HOME)/include;%(AdditionalIncludeDirectories)
diff --git a/src/openvpnmsica/openvpnmsica_resources.rc 
b/src/openvpnmsica/openvpnmsica_resources.rc
index ce60b4a1..9e8069f4 100644
--- a/src/openvpnmsica/openvpnmsica_resources.rc
+++ b/src/openvpnmsica/openvpnmsica_resources.rc
@@ -50,7 +50,7 @@ BEGIN
 VALUE "FileVersion", PACKAGE_VERSION ".0"
 VALUE "InternalName", "OpenVPN"
 VALUE "LegalCopyright", "Copyright © The OpenVPN Project" 
-VALUE "OriginalFilename", "openvpnmsica.dll"
+VALUE "OriginalFilename", "libopenvpnmsica.dll"
 VALUE "ProductName", "OpenVPN"
 VALUE "ProductVersion", PACKAGE_VERSION ".0"
 END
-- 
2.19.0.windows.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fopenvpn-develdata=02%7C01%7Cjkunkee%40microsoft.com%7C6dd3259ae2044b779b9a08d63351edc6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752824311161400sdata=6w%2FKO94p9LAx0%2FlamH4McJrCbJnDPwi%2F%2B6PDA6Ax4vY%3Dreserved=0

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

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

[Jon Kunkee via Openvpn-devel]

Hi Simon,

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.

>From what I gather, the OS version should be checked in the 
CustomAction's MSI execution conditions instead of in the CustomAction 
itself. The appropriate information can then be passed in based on that:

https://blogs.msdn.microsoft.com/cjacks/2009/05/06/why-custom-actions-get-a-windows-vista-version-lie-on-windows-7/

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-actions

Thanks,
Jon

-Original Message-
From: Simon Rozman  
Sent: Tuesday, October 16, 2018 3:26 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [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 the `InstallUISequence` only. The
`InstallExecuteSequence` is launched by msiexec.exe which we cannot
tamper with would still report `VersionNT` as Windows 8 (603).
---
 src/openvpnmsica/Makefile.am|   2 +-
 src/openvpnmsica/openvpnmsica.c | 124 ++--
 src/openvpnmsica/openvpnmsica.h |  15 
 3 files changed, 136 insertions(+), 5 deletions(-)

diff --git a/src/openvpnmsica/Makefile.am b/src/openvpnmsica/Makefile.am
index d46170b4..ecca74bc 100644
--- a/src/openvpnmsica/Makefile.am
+++ b/src/openvpnmsica/Makefile.am
@@ -41,7 +41,7 @@ libopenvpnmsica_la_CFLAGS = \
-municode -D_UNICODE \
-UNTDDI_VERSION -U_WIN32_WINNT \
-D_WIN32_WINNT=_WIN32_WINNT_VISTA
-libopenvpnmsica_la_LDFLAGS = -ladvapi32 -lole32 -lmsi -lsetupapi -lshlwapi 
-no-undefined -avoid-version
+libopenvpnmsica_la_LDFLAGS = -ladvapi32 -lole32 -lmsi -lsetupapi -lshlwapi 
-lversion -no-undefined -avoid-version
 endif
 
 libopenvpnmsica_la_SOURCES = \
diff --git a/src/openvpnmsica/openvpnmsica.c b/src/openvpnmsica/openvpnmsica.c
index 3b90ce05..d1642d6a 100644
--- a/src/openvpnmsica/openvpnmsica.c
+++ b/src/openvpnmsica/openvpnmsica.c
@@ -36,13 +36,15 @@
 #include 
 #include 
 #include 
-#ifdef _MSC_VER
-#pragma comment(lib, "shlwapi.lib")
-#endif
 #include 
 #include 
 #include 
 
+#ifdef _MSC_VER
+#pragma comment(lib, "shlwapi.lib")
+#pragma comment(lib, "version.lib")
+#endif
+
 
 /**
  * Local constants
@@ -119,7 +121,7 @@ openvpnmsica_setup_sequence_filename(
 {
 size_t len_action_name_z = 
_tcslen(openvpnmsica_cleanup_action_seqs[i].szName) + 1;
 TCHAR *szPropertyEx = (TCHAR*)malloc((len_property_name + 
len_action_name_z) * sizeof(TCHAR));
-memcpy(szPropertyEx, szProperty
 , len_property_name * sizeof(TCHAR));
+memcpy(szPropertyEx, szProperty
, len_property_name * sizeof(TCHAR));
 memcpy(szPropertyEx + len_property_name, 
openvpnmsica_cleanup_action_seqs[i].szName, len_action_name_z * sizeof(TCHAR));
 _stprintf_s(
 szFilenameEx, _countof(szFilenameEx),
@@ -142,6 +144,120 @@ openvpnmsica_setup_sequence_filename(
 }
 
 
+UINT __stdcall
+FindSystemInfo(_In_ MSIHANDLE hInstall)
+{
+#ifdef _MSC_VER
+#pragma comment(linker, DLLEXP_EXPORT)
+#endif
+
+#ifdef _DEBUG
+MessageBox(NULL, TEXT("Attach debugger!"), TEXT(__FUNCTION__) TEXT(" v")  
TEXT(PACKAGE_VERSION), MB_OK);
+#endif
+
+UINT uiResult;
+BOOL bIsCoInitialized = SUCCEEDED(CoInitialize(NULL));
+
+/* Set MSI session handle in TLS. */
+struct openvpnmsica_tls_data *s = (struct openvpnmsica_tls_data 
*)TlsGetValue(openvpnmsica_tlsidx_session);
+s->hInstall = hInstall;
+
+// Get Windows version.
+OSVERSIONINFOEX ver_info = { .dwOSVersionInfoSize = 
sizeof(OSVERSIONINFOEX) };
+if (!GetVersionEx((LPOSVERSIONINFO)_info)) {
+uiResult = GetLastError();
+msg(M_NONFATAL | M_ERRNO, "%s: GetVersionEx() failed", __FUNCTION__);
+goto cleanup_CoInitialize;
+}
+
+// The Windows version is usually spoofed, check using RtlGetVersion().
+TCHAR szDllPath[0x1000];
+ExpandEnvironmentStrings(TEXT("%SystemRoot%\\System32\\ntdll.dll"), 
szDllPath,
+#ifdef UNICODE
+_countof(szDllPath)
+#else
+_countof(szDllPath) - 1
+#endif
+);
+HMODULE hNtDllModule = LoadLibrary(szDllPath);
+if (hNtDllModule)
+{
+typedef NTSTATUS (WINAPI* fnRtlGetVersion)(PRTL_OSVERSIONINFOW);
+fnRtlGetVersion RtlGetVersion = 
(fnRtlGetVersion)GetProcAddress(hNtDllModule, "RtlGetVersion");
+if (RtlGetVersion)
+{
+

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

[Jon Kunkee via Openvpn-devel]

Samuli, LGTM.

-Original Message-
From: Simon Rozman  
Sent: Tuesday, October 16, 2018 3:26 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [Openvpn-devel] [PATCH 5/5] Detect TAP interfaces with root-enumerated 
hardware ID

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" HWID were detected by openvpn.exe.

The openvpnmsica.dll and tapctl.exe install TAP interfaces using root-
enumerated HWIDs, and were not detected by openvpn.exe.
---
 src/openvpn/tun.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 948fd17d..5fde2ab8 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -3524,7 +3524,8 @@ get_tap_reg(struct gc_arena *gc)
 
 if (status == ERROR_SUCCESS && data_type == REG_SZ)
 {
-if (!strcmp(component_id, TAP_WIN_COMPONENT_ID))
+if (!strcmp(component_id, TAP_WIN_COMPONENT_ID) ||
+!strcmp(component_id, "root\\" TAP_WIN_COMPONENT_ID))
 {
 struct tap_reg *reg;
 ALLOC_OBJ_CLEAR_GC(reg, struct tap_reg, gc);
-- 
2.19.0.windows.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fopenvpn-develdata=02%7C01%7Cjkunkee%40microsoft.com%7C4f51c53f4856475e3cab08d63351eb89%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752824282687252sdata=RkqbvXw2zxm00Np2Bb9C%2BeQstsTHkOHw25XtTyZYDII%3Dreserved=0


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

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

[Jon Kunkee via Openvpn-devel]

Hi Simon,

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

I would expect mingw to support .DEF files as well, but I don't know.

Only x86 Win32 functions are actually __stdcall; x64, ARM32, and ARM64 
all ignore the token because the architectural calling convention makes it
meaningless:
https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx

This is why the names don't get mangled. Of course, it's then inconsistent.

Export name consistency is needed so CustomActions can reference the 
export symbol name, right?

Jon

-Original Message-
From: Simon Rozman  
Sent: Tuesday, October 16, 2018 3:26 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [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.
---
 src/openvpnmsica/openvpnmsica.c | 12 
 src/openvpnmsica/openvpnmsica.h | 14 +++---
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/src/openvpnmsica/openvpnmsica.c b/src/openvpnmsica/openvpnmsica.c
index 82333991..3b90ce05 100644
--- a/src/openvpnmsica/openvpnmsica.c
+++ b/src/openvpnmsica/openvpnmsica.c
@@ -145,6 +145,10 @@ openvpnmsica_setup_sequence_filename(
 UINT __stdcall
 FindTAPInterfaces(_In_ MSIHANDLE hInstall)
 {
+#ifdef _MSC_VER
+#pragma comment(linker, DLLEXP_EXPORT)
+#endif
+
 #ifdef _DEBUG
 MessageBox(NULL, TEXT("Attach debugger!"), TEXT(__FUNCTION__) TEXT(" v")  
TEXT(PACKAGE_VERSION), MB_OK);
 #endif
@@ -247,6 +251,10 @@ cleanup_CoInitialize:
 UINT __stdcall
 EvaluateTAPInterfaces(_In_ MSIHANDLE hInstall)
 {
+#ifdef _MSC_VER
+#pragma comment(linker, DLLEXP_EXPORT)
+#endif
+
 #ifdef _DEBUG
 MessageBox(NULL, TEXT("Attach debugger!"), TEXT(__FUNCTION__) TEXT(" v")  
TEXT(PACKAGE_VERSION), MB_OK);
 #endif
@@ -505,6 +513,10 @@ cleanup_exec_seq:
 UINT __stdcall
 ProcessDeferredAction(_In_ MSIHANDLE hInstall)
 {
+#ifdef _MSC_VER
+#pragma comment(linker, DLLEXP_EXPORT)
+#endif
+
 #ifdef _DEBUG
 MessageBox(NULL, TEXT("Attach debugger!"), TEXT(__FUNCTION__) TEXT(" v")  
TEXT(PACKAGE_VERSION), MB_OK);
 #endif
diff --git a/src/openvpnmsica/openvpnmsica.h b/src/openvpnmsica/openvpnmsica.h
index 3a64fbaa..bb8e28ec 100644
--- a/src/openvpnmsica/openvpnmsica.h
+++ b/src/openvpnmsica/openvpnmsica.h
@@ -55,6 +55,14 @@ extern DWORD openvpnmsica_tlsidx_session;
 extern "C" {
 #endif
 
+#ifdef __GNUC__
+#define DLLEXP_DECL __declspec(dllexport)
+#else
+#define DLLEXP_DECL
+#define DLLEXP_EXPORT "/EXPORT:"__FUNCTION__"="__FUNCDNAME__
+#endif
+
+
 /**
  * Find existing TAP interfaces and set TAPINTERFACES property with semicolon 
delimited list
  * of installed TAP interface GUIDs.
@@ -64,7 +72,7 @@ extern "C" {
  * @return ERROR_SUCCESS on success; An error code otherwise
  * See: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Faa368072.aspxdata=02%7C01%7Cjkunkee%40microsoft.com%7C726e9ae5072942c989bf08d63351ec71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752824301952450sdata=BXt41C1200ZAAQBQBS7vOiAZ3MzuQGCVHaUuFhYwMCk%3Dreserved=0
  */
-__declspec(dllexport) UINT __stdcall
+DLLEXP_DECL UINT __stdcall
 FindTAPInterfaces(_In_ MSIHANDLE hInstall);
 
 
@@ -77,7 +85,7 @@ FindTAPInterfaces(_In_ MSIHANDLE hInstall);
  * @return ERROR_SUCCESS on success; An error code otherwise
  * See: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Faa368072.aspxdata=02%7C01%7Cjkunkee%40microsoft.com%7C726e9ae5072942c989bf08d63351ec71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752824301962454sdata=vMBtU2AQPrfZ9xnbN4nYZfcAb2wNlIxLPqqYLwDtvUc%3Dreserved=0
  */
-__declspec(dllexport) UINT __stdcall
+DLLEXP_DECL UINT __stdcall
 EvaluateTAPInterfaces(_In_ MSIHANDLE hInstall);
 
 
@@ -89,7 +97,7 @@ EvaluateTAPInterfaces(_In_ MSIHANDLE hInstall);
  * @return ERROR_SUCCESS on success; An error code otherwise
  * See: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Faa368072.aspxdata=02%7C01%7Cjkunkee%40microsoft.com%7C726e9ae5072942c989bf08d63351ec71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752824301962454sdata=vMBtU2AQPrfZ9xnbN4nYZfcAb2wNlIxLPqqYLwDtvUc%3Dreserved=0
  */
-__declspec(dllexport) UINT __stdcall
+DLLEXP_DECL UINT __stdcall
 ProcessDeferredAction(_In_ MSIHANDLE hInstall);
 
 #ifdef __cplusplus
-- 
2.19.0.windows.1



___
Openvpn-devel mailing list

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

[Jon Kunkee via Openvpn-devel]

> I gave the MsiBreak method a quick try, but I couldn't make it work. I have
> set MsiBreak as a system environment variable, restarted Windows Installer
> service, restarted the shell window from where I invoke msiexec calls to
> make sure the environment is updated. But it doesn't pop-up any prompt to
> attach debugger as advertised.

That's sad to hear. I'd toss out ideas to try, but...

> I haven't installed the Debugging Tools for Windows, as I run Visual Studio
> elevated to debug processes. I haven't restarted my computer: restart of a
> working machine with stage set to debug something is a royal PITA: the
> libopenvpnmsica.dll has more than one custom property to debug, restarting
> each time to switch MsiBreak to a different custom action is not viable.

I've debugged using MsiBreak set in the admin CMD prompt I used to launch the 
MSI, so restarts aren't required. The article goes into some very nearly useful 
details about when this is, but...

> Therefore, I'd prefer to keep own MessageBox() call in the beginning of each
> custom action. It works 100%.

...not only that, but the article even suggests this:

"To start debugging without MsiBreak, put a temporary message box at the 
beginning of the action's code. When the message box appears during the 
installation, attach the debugger to the process owning the message box."

If you ever need to debug say, the DLL loading, then MsiBreak is the way to go. 
As it stands, it's *REALLY* hard to beat 100%. :)

> Adding PID to the message is an option. I personally never needed it. When
> running Visual Studio elevated, you press Ctrl+Alt+P, followed by "msi"
> keystrokes to focus on "msiexec.exe" processes, then observe the
> MessageBox()'s title (which is deliberately set to function name) in the
> "Title" column of the available process list. Way faster than searching
> process by PID.

I've been wrong before about how easy different options are. :)

> Anyway, I have extended the debug pop-up dialogs to be more informative and
> include PID. Patch follows...

I took a look and it looks good to me, though I agree it's not strictly 
necessary. 

Thanks,
Jon



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

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

[Jon Kunkee via Openvpn-devel]

> Note a side take-home message: msiexec.exe will never be Windows 10 aware.

Unfortunately, yes.

> > Let me know if that doesn't make sense or won't work for what you're
> > doing.

> I am familiar with EXE and manifests, thanks. Nevertheless, I really
> appreciate your time to extensively research and provide useful references
> in the debate.

It looks like I erred widely on the side of overinforming. I appreciate your 
patience with that. 

> In my professional career I make EXE (or WSH) "parent installers" only
> because end-users usually have no clue what platform is their Windows. You
> can't do one-MSI-fits-all-platforms for native apps, so the parent installer
> EXE takes platform choice away from users. All other decision logic is
> inside MSI packages making them fully autonomous - once you pick the right
> one for your platform of course.

Makes sense. Fortunately x86 EXEs run on ARM64, so this even works 
there. :)

> When the MSI package is installed by Group Policy Client, the MSI is
> launched directly by msiexec.exe. 

Ah, I see. That puts a bit of a damper in bolting intelligence on during the 
msiexec invocation, doesn't it?

I'm no expert with GP, and what little I know suggests that any methods for
deploying custom EXEs through it are either much more complex than is 
feasible for you to support or otherwise not worth using. You're the expert 
between the two of us.

Without this ability and with the compat shimming of the MSI infrastructure,
there's not much else to be done. 

> Hence such a complex workaround to detect the MSI has been launched on
> Windows 10. Microsoft made me do it. ;)

:)

> Please, note one last thing... I totally agree with everybody saying "you
> That's why this custom action *does not* return the Windows version - not to 
> tempt anybody else to use it for OS version detection. 

> The name "FindSystemInfo" was picked generic on
> purpose, to allow us to add other detections missing in MSI should we need
> any down the road.

Smart! I hadn't followed the function to its callers, so I missed this.

Samuli, LGTM.

Thanks,
Jon


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

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

[Jon Kunkee via Openvpn-devel]

Hi Jon,

>> This approach keeps 'goes in DLL' next to the function itself, which I
>> like.
>
> It's ugly but it keeps both building systems happy and produces consistent 
> DLL file.

Fantastic. I'm sorry there isn't a more elegant solution, but I'm glad there's
something that works.

> I had to pick my poison, and I choose to fix issues as close to the source
> as possible.

Understood. Thanks for the explanation.

Samuli, LGTM.

Jon



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

Re: [Openvpn-devel] Slow outbound network speed for Windows Server 2016 only via the OpenVPN tunnel

[Jon Kunkee via Openvpn-devel]

> I don't know what causes this (the TAP driver?) but hopefully others may 
> chime in with some clue.

I wonder if this will be addressed by adding the missing buffer-remaining query 
OIDs. Unfortunately I don’t know enough to say for sure, but they are used for 
protocol behavior hinting.

My 2c,
Jon

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

Re: [Openvpn-devel] Slow outbound network speed for Windows Server 2016 only via the OpenVPN tunnel

[Jon Kunkee via Openvpn-devel]

(Side note: I do work for Microsoft, but I don't speak for Microsoft, don't 
know the networking stack well, and am not an NDIS dev.)

 I don't know what causes this (the TAP driver?) but hopefully others may 
 chime in with some clue.

>>> I wonder if this will be addressed by adding the missing buffer-remaining 
>>> query OIDs. Unfortunately I don’t know enough to say for sure, but they are 
>>> used for protocol behavior hinting.

Please note that this is just one theory. I don't currently have the networking 
expertise to determine what the problem is given the information in this 
thread, so it's possible something else entirely is the problem.

>> That was what I was hinting at too, but in the same boat here: not knowing 
>> enough about NDIS architecture I'm not in a position to make a patch for the 
>> missing OIDs.
>>
>> That said, as server 2016 uses the same kernel as Windows 10 (doesn't it?) 
>> such issues should show up on that platform too. Or are there some network 
>> protocol improvements that are enabled only on server 2016?

Windows Server 2016 is roughly equivalent to the Windows 10 Anniversary Update 
(1607), though it has more changes backported since its servicing-vs-upgrade 
cadence is very different from desktop Windows' cadence. That said, yes, it's 
the same kernel.

The question here is whether Server has more features lit up than client, and 
my digging suggests 'not in the TCP/IP stack'--but Server 2016 did have 
significant changes and does allow a lot more configuration (as described 
earlier with 'custom' profiles):
https://www.speedguide.net/articles/windows-10-anniversary-updates-to-tcp-6266

Server is more perf-sensitive than desktop, so it wouldn't surprise me if the 
Server 2016 TCP/IP stack started to rely on these OIDs for congestion control. 
The Server 2016 HLK tests do require that they be implemented. (This is one 
reason it is not (yet!) certified.)

If you're feeling daring, you could try rebuilding the driver with this 
extremely hacky change and see if the perf changes:
https://github.com/jkunkee/tap-windows6/commit/2706c9a98bd25a0fee6559ac132d75622475c26e

HTH,
Jon


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