Here's the summary of the IRC meeting.



Place: #openvpn-meeting on irc.freenode.net
Date: Wed 24th June 2020
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



cron2, dazo, lev, mattock, plaisthos and uip participated in this meeting.


Talked about the status of OpenVPN 2.5:


Ordex promised to have a look at the async-cc patches this week.
Plaisthos, dazo and cron2 will follow-up on the review comments to get
them resolved quickly.

OpenVPN 2.5 MSI looks surprisingly good. Mattock was able to produce
tap-windows6 MSM ("merge module") which he then used to produce OpenVPN
2.5-based MSI installer. The only significant challenge is adding
code-signing support to openvpn-build/generic.

Automating MSI builds also seems easier than expected, given that the
existing openvpn-build buildslave can perform the actual build and push
the artifacts to the Windows packager, which can then build and push the
results to build.openvpn.net.

Code-vise 2.5-alpha1 is in a good shape, mainly missing

- compression
- async cc
- VRF (which is quite trivial)

The auth-token fixes are corner-cases and it was agreed that that can be
resolved between 2.5-alpha1 and 2.5-beta1.


Talked about moving 2.3 into "oldstable" support mode. Previously we had
agreed to do that when 2.3.19 was released. However, 2.3.18 was released
a long while ago and there's nothing queued for 2.3.19. So it was
decided to move 2.3 to "oldstable" now instead of later.


Talked about starting the deprecation of "--ncp-disable". The idea is
that --ncp-disable has been mostly a debug feature and as we move
forward and want to be able to manage VPN security more from server
side, we want to abandon the possibility to ignore NCP.

This is tied with deprecation of --cipher for everything except p2p:


Uip will bring these topics up with syzzer a.s.a.p.


Talked about OpenVPN 2.6. There are several things that are 2.6 material:

- Kernel acceleration module (client-side only beta ~next week)
- Work related to "making DNS handling nice"

It is possible that we'd also need to postpone the --ncp-disable and
--cipher changes.

However, it was agreed that doing a "quick" 2.6 release in, say, early
2021 is doable. It was also agreed that supporting both 2.5 and 2.6 as
"stable" for a while would be acceptable, as the changes would be mostly
in OpenVPN and the same release and automation tooling could be used for


Talked about our use of IV_*. Agreed that rather than having tons of
IV_FOO=1 options IV_PROTO should be considered a wire-protocol-only
64-bit mask field and IV_FEAT would be a new 64-bit mask field
indicating which features the local side supports.

OpenVPN will need to handle a remote side not providing IV_FEAT.
Default behaviour when this field is missing must be documented.
IV_FEAT should be sent by OpenVPN 2.6 and newer. This approach allows
easier deprecation of features as well.


Full chatlog attached
(12:29:37) cron2: oh, a rare guest :-) - good morning uipko
(12:30:10) uip: morning
(12:30:21) dazo: hey!
(12:30:46) uip: trying to join the meetings more often
(12:31:59) dazo: that's great!
(12:32:34) plaisthos: hey
(12:32:39) lev__: hello
(12:32:52) uip: probably mainly reading/listening most of teh time ;)
(12:33:56) cron2: oh, feel free to take over and tell us what to do :-)  
(poking ordex and looking for lev__ ever so often starts to get boring)
(12:34:46) cron2: where is ordex anyway? :)
(12:35:09) dazo: Good question! :)
(12:35:36) mattock: hi!
(12:36:39) mattock: 2.5 updates first?
(12:37:11) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2020-06-24
(12:37:13) vpnHelper: Title: Topics-2020-06-24 – OpenVPN Community (at 
(12:37:32) cron2: first things first, and that's topic #1 :-)
(12:37:54) dazo: :)
(12:38:07) lev__: I will reply to plaisthos mail about optional compression, 
rebase my "fix some warnings" patch and write a test script/suite for testing 
async-cc (with the help of openvpn inc qa guy)
(12:38:24) dazo: So #1 means 
https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25  :)
(12:38:25) vpnHelper: Title: StatusOfOpenvpn25 – OpenVPN Community (at 
(12:38:32) lev__: sorry, was busy lately with corp stuff and midsommer 
(12:38:58) dazo: corp/kernel module stuff ;-)
(12:39:25) cron2: lev__: happy dance :-)
(12:40:32) dazo: ordex promised to have a look at the async-cc patches this 
week.  plaisthos and I can follow-up on review comments, to get them resolved 
(12:41:20) cron2: I expect that this will be somewhat more work than "just 
review comments" (restructure more, change patch granularity) - but I'm here to 
help as well.  Just not tomorrow, $kid[1] birthday
(12:41:56) mattock: MSI looks surprisingly good - openvpn-build/generic just 
needs code signing support
(12:42:03) cron2: my plate for 2.5 is emptying (and this is good).  Working on 
some trac tickets, windows tap config (with /64 or not? for tun mode or tap 
mode?) and the VRF patch
(12:42:12) mattock: I was able to produce tap-windows6 MSM (merge module) and 
use that to produce OpenVPN 2.5 MSI installer
(12:42:26) dazo: cron2: man-pages would really need some additional review 
before submitting patches to ML
(12:42:32) cron2: mattock: another happy dance :-)
(12:42:56) cron2: dazo: let's poke wiscii :-)  (but yeah, I'll see what I can 
get done)
(12:43:21) lev__: for async-cc testing I was planing to have 2 machines. One 
machine runs server with async-cc and few secs sleep, another one runs hundreds 
of clients which attempt to connect and disconnect, and some logic to check 
that all clients connected successfully
(12:43:26) cron2: .oO(did I mention that unit tests, autoconf, and shared 
library building across BSD, Linux and MacOS really take too much time?)
(12:43:47) lev__: I did something like that back in 2014 when we took that 
patch into use for freedome vpn
(12:44:21) mattock: also, automating the MSI builds may not be that horrible, 
either - I can reuse the openvpn-build buildslave to run openvpn-build/generic, 
sign the files and scp them over to a dedicated Windows box, which checks the 
file timestamps and triggers a build if those change -> scps results to 
(12:44:34) mattock: no need for Samba afaics
(12:44:38) cron2: lev__: yep, that's about what I did for the async-auth-pam 
setup.  One client is connected all the time, and noping verifies that ping 
works all the time, and "n" other instances connecting in a loop - some 
succeeding, some failing
(12:44:47) mattock: (our Windows node all have SSH enabled)
(12:44:51) cron2: mattock: more happy dances :)
(12:46:49) dazo: We have 6 more days for the code release ... are there items 
in the "must have" list we should reconsider?  Or some we will allow appearing 
a bit later after code freeze?
(12:48:13) cron2: there's not much left, actually, code-wise
(12:48:27) cron2: compression, async cc, VRF
(12:48:50) dazo: I'm wondering how much work the VRF will imply, and how well 
will we test it?
(12:48:51) cron2: the auth-token stuff is more "fixing corner case bugs", that 
can happen in beta I would say
(12:49:09) dazo: agreed
(12:49:10) cron2: I think the VRF stuff is totally trivial, I've just stalled 
for silly reasons
(12:49:26) dazo: okay, if it's trivial ... then this is doable
(12:50:12) cron2: it's not really "VRF" but "bind to device" - I wanted to get 
this "right" in a as generic fashion as possible, which took too much time.  
Max only wants (and tests) Linux, so this got stuck.  But, this week :-)
(12:50:36) cron2: if I do not have to build another MacOS test setup for engine 
(12:52:25) cron2: anyone else on 2.5?
(12:54:07) cron2: uip: anything from your end that you think we should address 
in 2.5?
(12:56:04) cron2: seems "nothing more on 2.5"
(12:56:10) cron2: topic #2 - "moving 2.3 into old stable"
(12:56:49) dazo: I spotted we said 2.3 would go into old stable with 2.3.19 ... 
but we haven't released anything there in quite some time and nothing 
(12:57:14) cron2: actually there is nothing in the release/2.3 branch after 
(12:58:26) dazo: Which is why I think 2.3 is ready for old-stable support :)
(13:00:12) cron2: doesn't look like i have to actively *do* anything for that, 
so I'm not objecting
(13:00:16) dazo: And we can consider what to do after 2.5 is released
(13:00:40) dazo: All needed is to update the wiki page
(13:01:12) dazo: 2.4 is aging and I would expect most users who would care to 
be on 2.4 already
(13:01:19) cron2: I would hope so
(13:02:23) dazo: alright, so unless noone disagrees ... lets move it to 
old-stable, to at least signal that
(13:02:45) dazo: s/noone/any one/
(13:03:03) dazo: gee my typing is horrendous today
(13:03:15) cron2: shall we do that togehter with the 2.5.0 announcement?  or 
(13:03:57) dazo: I would do it now, just to not needing to think about it
(13:04:23) dazo: once the 2.5.0 stable is out, we can decide if we're moving 
2.3 to "git tree only"
(13:05:05) cron2: ok.  #3 now?  "start depreciation of --ncp-disable"?
(13:05:55) dazo: plaisthos, this topic is probably something you can help us 
(13:07:23) dazo: the idea is that --ncp-disable has been more a debug feature 
... and as we move forward and want to be able to manage VPN security more from 
server side, we want to abandon the possibility to ignore NCP
(13:07:24) uip: Sorry, had also a stand-up meeting..
(13:07:44) mattock: uip: np
(13:08:41) plaisthos: I posted an idea how to handle that to the mailing list
(13:08:52) plaisthos: basically depreacted --cipher for everything but p2p
(13:08:53) dazo: This one, I believe: 
(13:08:54) vpnHelper: Title: Re: [Openvpn-devel] [PATCH] systemd: Change the 
default cipher to AES-256-GCM for server configs (at www.mail-archive.com)
(13:09:16) plaisthos: yes
(13:09:18) cron2: that's more topic #4 :)
(13:09:21) uip: I don't have any issue's. Last week we got a issue report from 
a user about fragmentation, but looks like a config issue. Not clear yet what 
he actually did..
(13:09:36) dazo: it's all tangled together ... --ncp-disable is just the first 
step :)
(13:09:56) cron2: I'd really like to hear syzzer's (and uip's!) thoughts on 
--ncp-disable and --cipher
(13:10:11) cron2: crypto people think different than network people
(13:11:42) dazo: We don't need to conclude today, but get the discussion and 
process started ... and if uip would like to dig into he topic first, that's 
fine for me.  But probably followup quickly on the ML
(13:11:52) cron2: yeah
(13:12:35) uip: I (also) have to discusse that syzzer (not enough cryptopeople 
yet ;)
(13:12:37) dazo: Since this is strictly not adding a new feature, we could 
probably allow related changes post code-freeze
(13:13:37) dazo: at the same time, I'm concerned how it may impact the release 
(13:16:12) cron2: this is why I've put #5 on the agenda :)
(13:17:25) uip: I'll pick this up with syzzer ASAP
(13:17:26) dazo: An alternative is that we just adds lots of warnings with 
related options for 2.5.0 + warn about these changes in release notes .... and 
then complete the transition in 2.5.3+ or so
(13:17:27) plaisthos: We can also ada that later
(13:17:37) cron2: uip: this is good, thanks
(13:17:49) dazo: plaisthos: "later" is kinda short time ... considering code 
freeze is in 6 days
(13:17:54) dazo: next meeting in 8 days
(13:18:14) cron2: dazo: doing possibly disruptive things in 2.5.*3* sounds like 
really bad plan
(13:18:26) cron2: we do if we must, but we do not *plan* on doing so
(13:18:28) dazo: cron2: agreed ... I don't like it either
(13:19:15) cron2: well
(13:19:27) dazo: uip: would you be able to follow up on ML later this week 
after discussing with syzzer?
(13:19:42) cron2: one idea, to test the waters: are we able to do a *quick* 
2.6.0 release?  like, early 2021?
(13:19:58) mattock: what is the schedule of the kernel module?
(13:20:08) mattock: that is "2.6 stuff" probably, if it is available
(13:20:27) cron2: these IV_PROTO changes you have suggested are something that 
can be done, but needs consideration, synchronization with AS release
(13:20:56) dazo: mattock: first public beta of kernel module with client-only 
support is expected next week
(13:21:09) cron2: so this whole "make DNS nice!" thing is not something we can 
get into 2.5 unless we postpone
(13:21:20) mattock: let's do quick 2.6 rather
(13:21:22) mattock: imho
(13:21:49) uip: dazo: it could be that syzzer is on holliday this week
(13:21:51) mattock: 2.5 has had its share of postponing already
(13:22:18) dazo: yeah ... but lets also keep the deprecated list in our minds 
at the same time ... 
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions ... we might need 
to reconsider some of them if 2.6 comes very early
(13:22:19) vpnHelper: Title: DeprecatedOptions – OpenVPN Community (at 
(13:23:24) dazo: alternatively, we keep 2.5 as a stable release for a longer 
period (now it is 6 months after last major release)
(13:23:34) dazo: well, minimum it says
(13:24:23) mattock: from my perspective maintaining 2.5 and 2.6 would be ok for 
a while
(13:24:24) cron2: I'm not holding my breath on "very early" :-)
(13:24:32) cron2: what mattock says
(13:24:41) mattock: unlike with 2.4 and 2.5 there would not many differences, 
mostly openvpn code
(13:24:51) mattock: 2.4 = NSIS, 2.5 = MSI, 2.6 = MSI
(13:25:12) mattock: same tooling can be used for 2.5 and 2.6 releases and 
(13:25:22) cron2: doubleplusgood
(13:25:56) mattock: so a "quick" 2.6 release with possibly overlapping 2.5 and 
2.6 "stable" support period is fine by me
(13:26:17) mattock: plus we would not have to postpone 2.5 _again_ and get more 
stuff queued and then have to postpone it _again_ :D
(13:27:00) cron2: yeah
(13:27:01) mattock: better draw a line and just accept that some stuff will 
have to come later
(13:28:48) cron2: dazo, plaisthos, lev__: thoughts?
(13:29:25) cron2: (I wonder if we should try jitsi with video for one of the 
next meetings... so we can see if one of you has just wandered away and it's no 
use waiting...)
(13:30:21) dazo: Yeah, I do not disagree ... that said, when plaisthos and I 
discussed the IV_PROTO stuff, we didn't really have that in the "we need this 
in 2.5".  If changes are untrivial, that's a different story ... but if it 
trivial and not putting anything at risk for the code-freeze, "why not"
(13:30:33) dazo: hehehe
(13:31:08) cron2: changing IV_ and figuring out who might interpret what on the 
other and, and how to avoid "interesting" complications is nontrivial
(13:31:37) cron2: AS has certain ideas on IV_ things...  people are running old 
AS release...
(13:32:03) cron2: so I'd like to see this documented *very soon*, but the 
actual code change to happen "in master after the 2.5.0 release"
(13:32:22) dazo: IV_PROTO changes is not risky, as that just documents coming 
features .... and we only have two valid values (1, 2) which fits within a 
(13:32:30) cron2: (also, I do not like overloading IV_PROTO with "non protocol 
related" things, so I'd go for IV_DNS=<bits>)
(13:32:53) cron2: it is, if we decide to remove IV_TCPNL=1 - this is really 
just a proto bit - but having that one go away will upset AS
(13:33:28) dazo: AS has been considered and we will handle that easily, so I'm 
not concerned with AS
(13:33:56) dazo: and by not using these new "DNS features", OpenVPN should 
behave as before
(13:34:04) lev__: I like IV_DNS
(13:34:35) dazo: We also want to reduce the number of IV_* stuff ... as that 
buffer is limited
(13:34:48) cron2: I really feel a bit strongly about IV_PROTO being "on the 
wire" bits, and other IV_ variables governing "what can happen with options"
(13:35:03) dazo: we consider IV_PROTO to be 64 bits ... it's more than enough 
(13:35:04) cron2: so, kick out IV_TCPNL=1, use these bytes for IV_DNS=
(13:35:18) cron2: but removing IV_TCPNL is not without risk
(13:35:22) dazo: Lets also think broader than just DNS
(13:35:27) cron2: I do :)
(13:35:53) dazo: That's why IV_DNS is limited ... IV_FEAT would probably be a 
better naming
(13:35:54) cron2: the compression stuff is PROTO in my mental image
(13:36:15) dazo: yeah, but we want to get rid of compression ... so we decided 
to keep it out of IV_PROTO
(13:37:28) plaisthos: lets focus on 2.5 now
(13:37:35) plaisthos: and try to make 2.6 quicker
(13:37:42) plaisthos: and maybe not with as many big changes
(13:37:54) mattock: +1
(13:38:11) dazo: plaisthos: thoughts on the  IV_* discussion?
(13:38:13) cron2: as long as we have compression, it might make sense to get 
these signalled more efficiently... I've just grepped on IV_ in one of my 
client logs, and about half the variables are "compression" (LZ4, LZ4v2, 
(13:38:44) cron2: s/v1/v2/
(13:39:27) dazo: yeah
(13:39:46) plaisthos: ignore AS consideration
(13:39:51) plaisthos: I will take care of AS
(13:40:05) ***cron2 likes that
(13:40:25) plaisthos: basically we want get rid of zillion IV_FOO=1 and 
therefore have something like a bitfield 
(13:40:48) cron2: I'm totally OK with that basic idea
(13:40:58) plaisthos: to extend IV_PROTO seemed like a good idea since that is 
already there
(13:41:45) dazo: and IV_PROTO is a nummeric field too
(13:41:48) plaisthos: we can also split it arbitrarely in to IV_FEAT and 
IV_PROTO if you pref
(13:42:40) lev__: we have changed IV_PROTO to 2 because we changed wire protocol
(13:43:02) lev__: DNS stuff is client behavior and not related to protocol
(13:43:13) cron2: this :-)
(13:43:29) cron2: I would feel better about IV_PROTO only being "wire protocol" 
(13:43:32) cron2: but that is too long :)
(13:44:10) dazo: alright, I'm fine with defining supported features in IV_FEAT 
and keep IV_PROTO strictly wire protocol
(13:44:57) dazo: and if we now define these as 64bit fields, we should be 
fairly future proof
(13:47:36) mattock: enough talk about this topic? :P
(13:47:53) ***plaisthos like his IV_ variables green
(13:48:00) dazo: hahaha
(13:48:17) dazo: plaisthos: I'll add a special patch colouring the logs, just 
for you
(13:48:27) cron2: plaisthos: log colouring is a GUI thing :-)
(13:48:50) plaisthos: cron2: IV_PROTO_green
(13:49:24) cron2: IV_LOGCOLOR=blue
(13:49:30) cron2: IV_BIKESHED=red
(13:50:04) mattock: as long as anyone can have their choice of log color I'm 
fine with this
(13:50:40) dazo: so ... the conclusion is:   IV_PROTO is considered a 64-bit 
mask field and IV_FEAT will be a new 64-bit mask field indicating which 
features the local side supports.
(13:50:56) dazo: should we also declare that IV_FEAT will always be sent to the 
remote side?
(13:51:50) dazo: Anyone disagreeing?
(13:51:52) cron2: on the server side you need to handle "no IV_FEAT" (old 
(13:52:09) cron2: on the client side you can mandate "always send IV_FEAT with 
all you can do"
(13:52:27) dazo: yes
(13:53:38) dazo: mattock: you're able to grasp that conclusion?
(13:53:48) mattock: I believe so yes
(13:53:57) dazo: good :)
(13:54:36) dazo: Anything else?
(13:56:02) mattock: please review:
(13:56:04) mattock: Talked about our use of IV_*. Agreed that rather than 
having tons of  IV_FOO=1 options IV_PROTO should be considered a 
wire-protocol-only  64-bit mask field and IV_FEAT would be a new 64-bit mask 
field  indicating which features the local side supports.
(13:56:04) mattock: On the server side you need to handle "no IV_FEAT" (old 
(13:56:04) mattock: On the client side you can mandate "always send IV_FEAT 
with all you can do".
(13:58:33) dazo: Can we simplify these two last lines?  cron2, what about:  
OpenVPN will need to handle a remote side not providing IV_FEAT.  Default 
behaviour when this field is missing MUST be documented.  IV_FEAT SHOULD be 
sent by OpenVPN 2.6 and newer.
(13:59:16) cron2: wfm
(13:59:36) dazo: This can also allow the server to indicate features to the 
client in the future.
(14:00:36) cron2: (that would even work for features going away, so "no IV_FEAT 
= can do DHCP, can do compression, ...", and if you/we ever rip out 
compression, that bit will be *sent* as 0, and that way it is clear to the 
server "this is a new client and it *stopped* supporting something 2.3 to 2.5 
could do"
(14:00:54) dazo: mattock: we are in agreement then .... replace the "On the 
(client|server)" with the "OpneVPN will need ...."
(14:00:58) dazo: cron2: exactly
(14:01:00) mattock: ok

Attachment: signature.asc
Description: OpenPGP digital signature

Openvpn-devel mailing list

Reply via email to