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

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

[Openvpn-devel] OpenVPN on ARM64 Windows

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

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

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

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

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

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

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.

Re: [Openvpn-devel] 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

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

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

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

> 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

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

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"

Re: [Openvpn-devel] OpenVPN on ARM64 Windows

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

Re: [Openvpn-devel] OpenVPN on ARM64 Windows

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

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

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:

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

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)

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

crosoft%2Fopenvpn%2Fdata=02%7C01%7Cjkunkee%40microsoft.com%7Cbd8e7cd00b2e4b35d04208d5e111f8df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662389663864307sdata=v%2Frbq%2F%2BJKjIbZTlgzrlIfMbfsHsM6raJFOBzdJlSs%2Fo%3Dreserved=0> > ? > > there are interesting things > >   > > вт, 3 июл. 20

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

> 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

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

> 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

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

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

> 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

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

(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