Here's the summary of the IRC meeting.



Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 4th September 2019
Time: 11:30 CEST (9:30 UTC)

Planned meeting topics for this meeting were here:


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



dazo, lev, mattock, ordex, plaisthos, rozmansi and syzzer participated
in this meeting.


Discussed HLK testing. As pointed out by rozmansi all of the tests don't
have to pass on the same HLK clients, and not all of the tests require a
physical HLK client. Therefore the following setup could possibly work
around the odd issues in mattock's physical HLK environment (possibly
related underlying network drivers):

- Virtualized HLK controller (Server 2016, already present)
- One physical HLK client (already present)
- One physical HLK support machine (already present)
- One virtual HLK client (for E2EPerf test, needs to be created)
- One virtual HLK support machine (for E2EPerf test, needs to be created)

This way E2EPerf traffic could run in fully virtualized environment and
thus avoid physical network/network driver-related problems.

Rozmansi also noted that Windows 10 1809 can be used for the majority of
the tests. Windows Server 2019 and Server 2019 Core is needed to pass a
couple of Server-specific tests only. Possibly those Server 2019 tests
could be run on virtual machines: this would circumvent the "Windows
Server 2019 driver support on real computers is poor" issue.

Agreed that at some point, maybe OpenVPN 2.6, it could be possible to
drop tap support altogether.

Also agreed that the main goal for tap-windows6 now is to get rid of the
unneeded HLK-testing complexity currently required for getting WHQL


Discussed the option of having tap emulation in OpenVPN. Basically it
would just allow connecting a tun client to tap server. Obviously
tap-specific features would not work, but basic connectivity would be there.


Full chatlog attached.
(12:44:38) mattock: mkay back at my computer
(12:45:23) mattock: seems like we don't have a topic list for today, probably I 
forgot to send the invitation
(12:45:43) mattock: in any case, I can give a brief update of everyone's 
favorite topic
(12:46:43) ordex: hi
(12:46:48) ordex: yeah
(12:46:49) ordex: :D
(12:47:06) mattock: to rule out the possibility of local issues in my physical 
HLK test environment (E2EPerf test) I've repeatedly tried to download the 
Virtual HLK but even getting it downloaded is a challenge
(12:47:30) mattock: the download seems to stop at 20GB even though the file 
size is claimed to be 31.5GB
(12:48:20) mattock: I also started fixing the EC2 HLK environment just so that 
I could test E2EPerf
(12:48:25) mattock: that is in progress
(12:48:40) ordex: is e2etest a required step for the certification ?
(12:48:43) mattock: yes
(12:48:55) ordex: and we haven't passed that in the physical env ?
(12:49:01) mattock: and it is known to pass - several people have made it pass 
in the past without any special trickery
(12:49:01) ordex: so you're trying to use the virtua env ?
(12:49:19) mattock: yes, to verify that the environment is to blame
(12:49:36) mattock: and then figure out what is the difference between working 
virtual environment and non-working physical environment
(12:49:44) ordex: oh ok
(12:49:51) ordex: because we don't really know why it fails, right ?
(12:50:01) mattock: at this point I'm blaming the underlying network drivers in 
Windows Server 2019 (they're the stock drivers), but I could be wrong
(12:50:02) ordex: don't we get any feedback about the failure ?
(12:50:15) mattock: exactly, there is thousands of lines of debug logs but 
nothing useful
(12:50:36) lev__: are all those troubles because of tap?
(12:50:40) mattock: packet capture logs show lots of TCP-related errors 
(duplicate ACKs and such)
(12:51:20) mattock: I'm not sure what the problem is, but the logs don't show 
anything useful
(12:51:49) mattock: except that possibly the backchannel connection (=the one 
going to the "corporate network") stops working at some point for unknown 
(12:52:08) mattock: anyways, I need to make the test pass in some environment 
so that I can compare
(12:52:20) mattock: EC2 seems the path of least resistance, given the issues 
with VHLK
(12:53:12) lev__: do you think we can speed up this process by dropping tap 
(12:53:12) mattock: also, as rozmansi kindly pointed out that ARM64 with secure 
boot requires WHQL/HLK-tested drivers
(12:53:35) mattock: lev__: we had that discussions in the past and agree we 
really can't / should not at this point
(12:54:42) mattock: anyways, the HLK testing environment will need to grow over 
time, and in my opinion we should do our best to outsource it once we get the 
first HLK-tested release out
(12:54:54) mattock: otherwise my HLK workload will only increase over time
(12:55:05) mattock: something I'm not really looking forward to
(12:55:16) mattock: HLK is a huge timesink if/when something does not work as 
(12:55:24) rozmansi: mattock1: _any_ windows with secure boot require WHQL 
drivers. :(
(12:55:29) mattock: ah hi
(12:55:33) rozmansi: hi
(12:55:34) mattock: that's even worse then
(12:55:45) mattock: rozmansi: now that you're here
(12:55:53) rozmansi: you mentioned my name an I got a notification - didn't 
know there's a meeting today :(
(12:55:59) mattock: what is the correct file size for the VHLK 1809 vhdx file?
(12:56:17) mattock: my downloads stop at 20GB and converting to vdi format 
fails at 30%
(12:56:29) mattock: download is supposed to 31.5GB according to the browser
(12:56:41) rozmansi: dunno, haven't saved it :) but I didn't have _any_ issues 
downloading it. More than once.
(12:56:56) mattock: interesting
(12:57:01) mattock: I'm using Linux though :)
(12:57:20) rozmansi: Maybe microsoft.com is alergic to linux. :(
(12:57:27) mattock: I would not be surprised
(12:57:44) mattock: though the download seems also allergic to Microsoft Edge 
(or Microsoft Edge is allergic to large downloads)
(12:57:45) rozmansi: i've used firefox on windows
(12:57:58) mattock: I'm now downloading it on Chrome on Windows ARM64
(12:58:04) rozmansi: microsoft doesn't eat its own cooking
(12:58:19) ordex: I can download it too and ship you a pendrive if you think it 
makes sense :D
(12:58:25) rozmansi: for the most of the time MSDN worked worst with Internet 
(12:58:32) mattock: ordex: I hate to say but that might actually make sense lol 
(12:58:44) mattock: rozmansi: I was unable to start the download using IE
(12:58:57) ordex: mattock1: have you tried from a different internet connection 
(12:59:00) ordex: i.e. home vs office ?
(12:59:06) ordex: maybe it's some provider thing too
(12:59:13) rozmansi: another thing: vhdx can be converted to .vdi and run by 
(12:59:16) mattock: though it was on Server 2016 so all the security stuff got 
in the middle
(12:59:17) ordex: that kills long lasting connections..because it must be wrong 
(12:59:23) syzzer: mattock1, rozmansi: I'm mostly clueless regarding the whole 
windows driver signing, but a colleague of mine told me yesterday that you can 
often avoid the difficult parts by marking the driver as "demand_start” instead 
of "boot_start"
(12:59:33) syzzer: maybe this rings a bell for you guys?
(12:59:53) mattock: rozmansi: yes, I tried that, but the file seemed incomplete 
and hence the conversion stopped at 30%
(12:59:53) syzzer: (since you're talking about secure boot requirements)
(12:59:57) mattock: at 20GB
(13:00:43) mattock: ordex: I'm not 100% sure, but I can try a mobile connection
(13:00:44) mattock: anyways
(13:01:17) rozmansi: syzzer: nope, I don't think so... the tap-windows6 is not 
a PnP device that could trigger a demand_start driver. It's a virtual device 
that is not "plugged in".
(13:01:46) syzzer: ah, okay. and chaging that is not easier than fighting the 
test setup?
(13:01:51) mattock: one more question to our resident Windows expert
(13:02:04) mattock: one of the problems with physical Windows Server 2019 
instances is driver support
(13:02:37) mattock: do you know if it is possible to completely disable the 
driver signing requirement on Server 2019 and if yes, would standard Windows 10 
drivers work ok on it?
(13:03:15) mattock: to rule out issues with the stock (network) drivers that 
Windows Server 2019 is using out of the box
(13:03:26) rozmansi: mattock1: you already did `bcdedit /set testsigning on`, 
(13:03:54) mattock: yes, but I mean disabling the signing requirement altogether
(13:04:18) mattock: so that I could install, say, Lenovo's Windows 10 ethernet 
card drivers for the HLK client computer
(13:04:34) mattock: without importing Lenovo's driver signing cert into the 
certificate store
(13:04:52) rozmansi: that should work
(13:05:15) rozmansi: win10 1809 release and winsrv2019 are one and the same core
(13:05:25) rozmansi: maybe your server has secure boot enabled?
(13:05:46) mattock: the HLK client is a fairly recent (~1 year old) Lenovo 
Thinkcentre, and the support machine is pretty old Thinkpad L420, and most of 
the devices don't have driver support at all
(13:05:57) mattock: I have to check those details
(13:06:26) dazo: [thinking a bit forward] The more I see this tap-windows6 
fighting ... I begin to wonder if we really need to replace it with a proper 
plain tun driver .... and for those needing to connect to a TAP based server, 
that we emulate TAP instead in OpenVPN ... we will loose those doing bridging 
or depending on OSI Layer 2/Ethernet frames on Windows - but how big is this 
user base?
(13:07:17) ordex: you mean tap emulation won't work when using windows ?
(13:08:23) dazo: ordex: that would mean the driver would need TAP mode.  But if 
it is a plain TUN driver, OpenVPN can remove the Ethernet frame and pass the 
TCP/IP packet directly to the tun driver
(13:08:35) ordex: ah ok
(13:08:46) ordex: but wouldn't this probem also exist on linux then ?
(13:09:03) dazo: it's the TAP mode in the driver making this certification 
explode in complexity on Windows
(13:09:21) rozmansi: mattock1: you can use Windows 10 1809 to do majority of 
the tests. You need a Windows Server 2019 and Server 2019 Core to pass some 
Server-specific tests only. But those are like two or three test IIRC. And 
probably they'd run on a virtual Windows Server 2019 too.
(13:09:24) ordex: or we keep the linux side as it is now without changing 
anything ?
(13:09:40) dazo: ordex: well, the TAP emulation could work on all platforms 
.... Some Android/iOS users would probably like this feature too
(13:09:59) ordex: dazo: what would tun+emulation be useful for actually? if you 
lose all the advantages of L2 ?
(13:10:00) rozmansi: mattock1: you don't need to pass _all_ tests on the same 
test machines.
(13:10:03) dazo: ordex: but the primary goal is to get rid of the TAP 
complexity in the tap-windows6 certification
(13:10:17) ordex: yap yap, I agree with gettind rid of the complexity
(13:10:25) dazo: ordex: to support those servers configured with TAP
(13:10:39) ordex: ok, so just to allow the connection to a tap server
(13:10:41) ordex: okok
(13:10:52) dazo: yeah
(13:11:22) dazo: it won't be feature complete compared to a full blown TAP 
setup ... but at least you can connect and pass traffic
(13:11:49) mattock: rozmansi: yes, that is a thought that also came to mind - 
pass e2eperf virtualized, then merge the results with the physical HLK results
(13:12:08) mattock: but I still need a HLK environment where e2eperf test passes
(13:12:30) mattock: which is doable, but VHLK and EC2 are both fighting back, 
so I have to force them to comply
(13:12:53) mattock: I have to say that HLK has proven a tough foe to beat lol :D
(13:13:12) ordex: dazo: yap yap okok
(13:13:24) rozmansi: mattock1: you don't even need to merge. Just put some 
physical Windows 10 1809 boxes and some virtual Server 2019 into the same 
network controlled by the same WHLK controller. And when you schedule tests, 
you can pick which computer to schedule which test.
(13:13:46) rozmansi: VHLK == HLK where controller is virtual
(13:15:28) mattock: rozmansi: hmm, that might work, especially if I had this 
(13:15:28) mattock: - virtual controller
(13:15:28) mattock: - virtual client + virtual support machine
(13:15:28) mattock: - physical client (+ physical support machine)
(13:16:22) mattock: that way e2eperf test would go through virtualized network
(13:16:27) mattock: would/could
(13:16:35) mattock: anyways, more things to try out
(13:16:38) rozmansi: for HLK you need:
(13:16:38) rozmansi: - one Windows Server !!!2016!!! - can be physical or 
virtual. If virtual, Microsoft has already prepared a box you can use. It's 
called VHLK.
(13:16:38) rozmansi: - test computers that must all match 1809 - be physical or 
virtual. Some test require physical, most work on virtual just fine)
(13:17:03) mattock: yes, my controller is already 2016 and it is virtualized
(13:17:13) mattock: it has always been
(13:17:24) rozmansi: then you _dont_ need VHLK download
(13:17:44) rozmansi: you'll just get another server 2016 with HLK controller 
(13:18:09) mattock: yeah, it is probably redundant anyways, as installing HLK 
is not very difficult
(13:18:13) mattock: the controller
(13:18:32) mattock: anyways I think we can move on if there are other topics
(13:20:21) rozmansi: dazo: is dropping support for tap-windows6 viable for 2.5 
Windows release?
(13:20:53) dazo: rozmansi: no, I think that's too early, unfortunately ... but 
for 2.6 we should definitely consider it
(13:21:23) rozmansi: dazo: thanks. This means I need to make a proper driver 
installer for MSI packages for 2.5 then.
(13:21:49) dazo: We can discuss this on the Hackathon ... might be I'm just too 
pessimistic in regards to 2.5 :)
(13:25:38) mattock: meeting concluded or something else to discuss?
(13:26:28) mattock2 ha abbandonato la stanza (quit: Quit: IRC for Sailfish 0.9).
(13:31:05) mattock: writing the summary
(13:31:09) ***syzzer is off for lunch :)
(13:31:20) mattock: have a good one!

Attachment: signature.asc
Description: OpenPGP digital signature

Openvpn-devel mailing list

Reply via email to