Hi,
Here's the summary of the IRC meeting.
---
COMMUNITY MEETING
Place: #openvpn-meeting on libera.chat
Date: Wed 1st December 2021
Time: 14:00 CET (12:00 UTC)
Planned meeting topics for this meeting were here:
<https://community.openvpn.net/openvpn/wiki/Topics-2021-12-01>
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
dazo, d12fk, lev, mattock, plaisthos and rob0 participated in this meeting.
---
Talked about OpenVPN 2.5.5. Mattock provided preview installers with
2.5.4 label for it last week:
<https://build.openvpn.net/downloads/temp/OpenVPN-2.5.4-I605-amd64.msi>
<https://build.openvpn.net/downloads/temp/OpenVPN-2.5.4-I605-arm64.msi>
<https://build.openvpn.net/downloads/temp/OpenVPN-2.5.4-I605-x86.msi>
These installer have not yet been thoroughly tested. Once they are, we
can push out 2.5.5.
---
Talked about the status of OpenVPN 2.6:
<https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26>
D12fk started looking at the new dns option today.
Dazo's potential fix to the multiple auth-plugin mess is in internal
review and once that's done it will go to the mailing list. Dazo will
provide a similar fix for 2.5.
Plaisthos has two patchsets pending. the first one is changing cipher
and auth from cipher_kt to const char and the second is the buffer
overhaul, which will change the wacky and incorrect mssfix calculation.
Talked about split-dns in the context of 2.6. Agreed that full split-dns
support is for 2.7, even if we happen to include some parts of it in 2.6.
---
Talked about extending t_client tests. This, in combination with the new
buildbot infrastructure, will allow developers to test potentially
breaking changes easily with good test coverage. Mattock can finally
start creating the new buildbot production infrastructure (all blockers
have been resolved).
---
Talked about moving 2.4 to oldstable. There have been no issues with 2.4
since latest June, so it should be doable.
--
Full chatlog attached
(14.58.41) mattock: almost time
(15.00.26) d12fk: ready
(15.01.15) plaisthos: me too
(15.01.21) dazo: hoho!
(15.01.35) rob0: oyez
(15.02.08) lev__: hello
(15.03.27) mattock: hi!
(15.04.39) mattock: cron2?
(15.05.10) mattock: fact of today: "dwz: debian/openvpn/usr/sbin/openvpn: DWARF
compression not beneficial - old size 1215239 new size 1244553"
(15.07.43) dazo: mattock: cron2 said yesterday he would miss the meeting today
(15.07.49) mattock: ah
(15.07.50) mattock: ok
(15.07.56) mattock: let's start then
(15.08.00) dazo: +1
(15.08.07) mattock: sync up for 2.5
(15.08.19) mattock: where are we at on that front?
(15.08.50) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2021-12-01
(15.11.07) dazo: lev__: ^^^ maybe you know a little bit, in cron2's absence?
(15.11.21) mattock: I only know that I provided "almost 2.5.5" installers last
week
(15.11.37) mattock: basically "latest release/2.5" with 2.5.4 label
(15.12.04) dazo: It might just need some testing and then tagging the release
and start the release machinery
(15.12.24) lev__: yeah I cannot add much, been reviewing/fixing some (minor)
openvpn-gui issues and talking with MSFT about publishing openvpn to windows
store
(15.12.25) mattock: that was my understanding as well
(15.12.49) dazo: Latest change to release/2.5 is Nov 24 ... so sounds the core
part is essentially good to go, just the GUI and installer aspects left
(15.13.53) dazo: so next topic?
(15.14.01) mattock: fine by me
(15.14.02) mattock: 2.6
(15.14.36) d12fk: I started looking at the new dns option today
(15.14.37) dazo: https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26
(15.15.07) d12fk: reminder: patches will come as github PRs
(15.15.46) plaisthos: why?
(15.15.55) plaisthos: for the first review?
(15.16.11) dazo: I've sent a potential fix the multiple auth-plugin mess to an
internal review ... if that looks good, I'll send it to the public mailing
lists together with a similar fix for at least 2.5
(15.16.29) d12fk: plaisthos: as a test if we live up to "you can contribute via
github as well"
(15.17.18) mattock: yes, we've essentially allowed that for two years
(15.17.40) mattock: but never really tested it ourselves to see how it goes
(15.17.43) dazo: for initial reviews, GH pull-reqs are okay, but once all is
settled and it needs to hit the mailing list for the official ACK ... otherwise
all fine
(15.17.44) plaisthos: I have two patchsets pending that are not yet on the list
since I want to test them some more
(15.18.09) plaisthos: the first one is changing cipher and auth from cipher_kt
to const char
(15.18.18) plaisthos: and the second is the buffer overhaul
(15.20.20) dazo: the buffer overhauls is part of the "frame/buffer size
handling" item?
(15.20.26) ***dazo looks at
https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26
(15.20.30) plaisthos: yes it is basically that
(15.20.38) plaisthos: it will change mssfix calculation
(15.20.44) dazo: +1
(15.20.46) plaisthos: since the current one is wacky and incorrect
(15.20.54) plaisthos: but we need to discuss something else
(15.21.14) plaisthos: as part of that patch set I want to set the default mtu
to something saner than 1500, like 1420
(15.21.28) plaisthos: to not need mssfix by default
(15.21.30) dazo: That makes sense
(15.21.38) plaisthos: but raises the question how to specify the mtu value for
OCC
(15.21.44) plaisthos: do we want occ-mtu?
(15.22.56) dazo: I don't think we want occ-mtu ... but if we can't escape it in
a sane and reasonable way, we might need to accept that fact
(15.23.06) rob0: d12fk, "split DNS," this means split where client queries are
sent by some criteria?
(15.23.24) plaisthos: I don't see another way unfortunately
(15.23.43) dazo: rob0: Johan put together the final agreement on the hackathon
.... somewhere
(15.23.52) plaisthos: default behaviour of 2.6 would be, nothing specified =>
tun-mtu 1420, occ-mtu 1500
(15.24.10) plaisthos: tun-mtu only, both occ-mtu and tun-mtu are set to tun-mtu
(15.24.26) plaisthos: and both specified set both things
(15.24.28) d12fk: rob0: by domain name. but it won't be part of 2.6 by agreement
(15.24.52) plaisthos: d12fk: well, it can be part of 2.6
(15.25.00) d12fk: we want dco out, thus split comes later
(15.25.01) plaisthos: but it is not considered needed for 2.6 to release
(15.25.41) dazo: well, not complete split-dns support ... but the option
parsing for it, and capability to understand the options to the level we
support DNS configs today, right?
(15.25.44) d12fk: remember the "keep release smallish" discussion
(15.26.31) d12fk: yeah the option parser will not bail out if it sees something
it doesn't support
(15.26.42) plaisthos: but we should not stop development after the minimal set
is in
(15.26.49) plaisthos: but also develop the split DNS
(15.27.03) dazo: yeah, and full split-dns is 2.7 material
(15.27.04) plaisthos: so we don't need another 2 years until that is done
(15.27.07) d12fk: that's the plan
(15.27.21) dazo: +1
(15.27.56) dazo: plaisthos: regarding occ-mtu .... lets go for that for now,
and we'll see if we can slim down these aspects later on
(15.28.37) plaisthos: dazo: Ignoring that problem that does not make it go away
:)
(15.29.02) plaisthos: also the patchset introduces mtu keyword to --fragment
and --mssfix
(15.29.14) plaisthos: to include the ip/udp overhead
(15.29.51) plaisthos: e.g. mssfix 1450 mtu means that the resulting packet
including ip/udp header of the outer IP does not exceed 1450
(15.29.57) dazo: I don't think I said we should ignore that that problem, just
postpone it so we can move forward one step ;-)
(15.31.07) dazo: should we name it force-mtu? Just thinking aloud again
(15.32.33) d12fk: the force doesn't have an MTU, it is unlimited, and very
strong in the young skywalker =)
(15.33.48) dazo: :-D
(15.39.37) d12fk: i think 2.6 discussion died off (not my fault), move on?
(15.39.43) dazo: +1
(15.40.03) d12fk: testing then
(15.40.26) d12fk: I'm all for it, but who?
(15.42.07) mattock: plaisthos may explain what kind of testing he is thinking of
(15.42.20) d12fk: are there existing test automation frameworks which support
multi platform?
(15.43.08) plaisthos: dazo: hm, what would force-mtu do?
(15.44.05) plaisthos: well basically for any change that we do in OpenVPN, we
have to manually run test to see if there is any regression in normal behaviour
(15.44.10) plaisthos: that is tedious and error prone
(15.44.19) plaisthos: so automation would be great
(15.44.20) dazo: plaisthos: no, no, nothign new ... just the mtu flag you
propose for --mssfix
(15.44.27) rob0: depends on the value of --side (light or dark)?
(15.44.43) rob0: scnr
(15.44.47) dazo: :-P
(15.45.15) mattock: plaisthos: suppose there is a problem - how would you
notice it? what kind tests would you run?
(15.46.22) mattock: basically: is extending t_client tests a/the solution? or
some completely different types of tests?
(15.47.31) plaisthos: extending t_client would be good
(15.47.47) plaisthos: dazo: the mtu flag is not my idea
(15.47.54) plaisthos: dazo: that is openvpn3 syntax
(15.48.11) dazo: ahhh, okay ... I was not aware of that
(15.48.11) plaisthos: we can choose something else but then we should also add
the something else to openvpn3
(15.48.35) dazo: right, well, that's another discussion then
(15.50.15) plaisthos: but my mssfix 1300 mtu really ends up with 1300 bytes
packets :)
(15.50.17) mattock: plaisthos: if you can provide client/server configs
suitable for testing then we could extend t_client
(15.52.23) dazo: will that be sufficient? does our github actions or buildbot
builds also run the t_client.sh tests?
(15.53.36) mattock: buildbot does
(15.54.04) mattock: and finally after all these months we can actually spin up
a production buildbot (starting next week, once all the infrastructure is
prepared)
(15.54.07) dazo: okay, that's good ... plaisthos you got access to kick off
builds with buildbot?
(15.54.16) mattock: there is one gotcha
(15.54.26) mattock: right now buildbot t_client tests run from docker containers
(15.54.29) plaisthos: dazo: maybe?
(15.54.34) plaisthos: Never done that
(15.54.36) mattock: that may or may not be a problem
(15.54.43) plaisthos: that is probably a problem
(15.54.55) mattock: it can be extended to run tests on real VMs of course
(15.54.58) dazo: mattock: depends if the docker container is running with
enough privileges or not
(15.55.02) mattock: it has
(15.55.05) plaisthos: hmpf
(15.55.07) mattock: t_client itself works fine
(15.55.19) plaisthos: macos utun forces MRU to be the same as MTU
(15.55.32) plaisthos: so you don't get away with receiving larger packet than
you can send
(15.56.54) dazo: okay, so lets see how we can get plaisthos (and other core
developers) to kick off t_client test runs via the new buildbot infrastructure
once ready
(15.58.01) mattock: +1
(15.58.49) dazo: so 2.4 to oldstable?
(16.00.12) User89 [~u...@90-145-31-194.bbserv.nl] è entrato nella stanza.
(16.00.21) User89 ha abbandonato la stanza (quit: Client Quit).
(16.01.40) mattock: was this about "one last 2.4 release"?
(16.08.38) mattock: ok so this meeting died out :D
(16.09.42) rob0: it was the Dark Side
(16.11.58) rob0: anyway, dazo or d12fk, I am interested in reading about the
split DNS feature. Can you point me to Johan's hackathon writeup, or should I
just ask Johan?
(16.12.13) d12fk: i can send it to you
(16.13.14) dazo: mattock: yes
(16.14.03) dazo: one last 2.4 release. We can consider to backport the
multi-auth plugin "fix" to 2.4 as well, and consider that part of the final
release before oldstable
(16.15.33) d12fk: rob0: it is not entirely about split-dns, rather an overhaul
of dns related options
(16.15.50) d12fk: in preparation for things to come
(16.15.59) dazo: there are a few minor fixes already queued up since June ....
so I don't there are any big issues hiding in 2.4 now
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
