Hi,
Here's the summary of the IRC meeting.
---
COMMUNITY MEETING
Place: #openvpn-meeting on libera.chat
Date: Wed 11th May 2022
Time: 10:30 CEST (9:30 UTC)
Planned meeting topics for this meeting were here:
<https://community.openvpn.net/openvpn/wiki/Topics-2022-05-11>
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
cron2, dazo, d12fk, lev, mattock, MaxF, ordex and plaisthos participated
in this meeting.
---
Talked about OpenVPN 2.5.
Mattock will spin up a new Windows installer to fix some OpenVPN-GUI
issues. Luckily OpenVPN was not affected by the OpenSSL issues fixed
since our previous installer release.
---
Talked about OpenVPN 2.6.
D12fk will submit a path this week which add a --dns-support bit to
IV_PROTO. It is mostly for servers to be able to not push --dns to
non-compliant clients, to avoid warnings in log files, which reduces the
potential of clueless support tickets.
The HMAC stuff is all in, thanks to djpig and ordex for lots of review
rounds + testing.
The xkey patch is waiting for review (from Selva or someone else).
---
Talked about the fix to broken TCP connections on Windows Server 2022:
<https://github.com/OpenVPN/tap-windows6/pull/147>
Lev will ask Simon to give his feedback in the PR, in addition to
already having given it privately.
--
Full chatlog attached
(11.29.54) mattock: hi
(11.30.28) cron2: yo!
(11.31.08) d12fk: hello
(11.32.17) MaxF: hi!
(11.33.40) mattock: I have about 20 minutes, then I need to head to lunch - can
follow the discussion with my mobile though
(11.33.53) cron2: you and your food desires... :-)
(11.34.06) cron2 ha scelto come argomento:
https://community.openvpn.net/openvpn/wiki/Topics-2022-05-11
(11.34.27) d12fk: .fi food schedule is slightly shifted, both timezone and
cultural reasons
(11.34.33) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2022-05-11
(11.36.39) cron2: so - 2.5 updates?
(11.36.51) plaisthos: moin moin
(11.36.59) dazo: moin
(11.37.09) d12fk: I'll submit a path this week which add a --dns-support bit to
IV_PROTO
(11.37.11) mattock: 2.5 installer-vise no, but I'll do a build later today
(11.37.22) mattock: tested lev's new Windows build process and it seems to work
(11.37.34) mattock: installer + new build process are not strictly related
though
(11.37.53) cron2: d12fk: why?
(11.38.24) cron2: (as in "the server can just push both, without doing harm")
(11.38.44) d12fk: yes, plaisthos requested it for AS
(11.39.03) cron2: so you want to avoid warnings if pushing to an "old" client?
(11.39.20) d12fk: concern ist customers getting worried for no reason
(11.39.23) dazo: cron2: it's more for servers to be able to not push --dns to
non-compliant clients, to avoid warnings in log files, which reduces the
potential of clueless support tickets
(11.40.01) cron2: so, "yes" :)
(11.40.10) cron2: (not exactly a 2.5 topic, tho)
(11.40.20) d12fk: yeah, my fault
(11.41.16) cron2: but we seem to have nothing else on 2.5 anyway ;-) (except,
for the minutes "we are not vulnerable to the new openssl security issues, but
we still release a new installer due to our own bugs")
(11.41.22) cron2: so, 2.6
(11.41.33) cron2: "there will be an IV_PROTO bit for DNS" ;-)
(11.42.14) cron2: the HMAC stuff is all in (thanks, djpig and ordex, for lots
of review rounds + testing)
(11.42.18) ordex: hi
(11.42.22) plaisthos: I made a patch for ed448/ed25519 for xkey_provider
(11.42.50) cron2: freebsd openvpn-devel port has been updated to master "as of
last friday", so we might see bug reports
(11.43.14) ***cron2 hopes Selva finds the xkey patch interesting and tests &
ACKs :-)
(11.43.22) plaisthos: I still need to do the mtu 1400 by default patch
(11.43.29) plaisthos: cron2: yeah it is not something urgent
(11.43.47) plaisthos: who you will currently be hardpressed to find something
that already supports these certificates
(11.43.56) cron2: ah, plaisthos: does "--mtu-disc yes" work with the
control-channel MTU patches?
(11.44.40) cron2: so, if I send a control-channel packet and get back a socket
error "packet too big", will it influence both control+data channel MTU
settings?
(11.44.54) plaisthos: mtu-disc is data channel iirc
(11.45.13) cron2: mtu-disc is "make the socket don't fragment and report
errors", so that affects control packets as well
(11.45.13) plaisthos: but it won't chagne control channel settings
(11.45.20) mattock2 [~ya...@mobile-access-bcee25-0.dhcp.inet.fi] è entrato
nella stanza.
(11.45.21) cron2: mtu-test is "DCO"
(11.45.49) plaisthos: and it never really worked
(11.46.07) cron2: which one?
(11.46.20) plaisthos: because it kicks in after the control channel has been
already established and OpenVPN lacks the ability to resend and split packets
(11.46.27) plaisthos: (on a protocol level)
(11.47.07) plaisthos: TCP does ACK bytes instead of packets for a good reason,
so you can try sending less without getting confused about packet id acks (this
is the original too big packet being acked or the smaller resend?)
(11.47.23) cron2: oh
(11.47.48) cron2: so if we send a packet with 1400 bytes, get back a "too big!
max = 1000", we're lost, because we can only re-send the 1400 byte packet?
(11.48.19) plaisthos: yes
(11.48.31) cron2: there goes my hope for working --mtu-disc for control-plane...
(11.49.47) plaisthos: that can of course all be fixed/implemented but it will
not work without protocol enhancements
(11.51.01) cron2: yep
(11.51.58) cron2: speaking of --mtu-disc, even if of limited use, we still
don't do this for "over IPv6" packets...
(11.52.00) plaisthos: but with the default tls-mtu of 1250 which includes
ip/udp overhead I don't think we would run into that
(11.52.07) cron2: there is a patch in patchwork, waiting for an ACK...
(11.52.09) cron2: https://patchwork.openvpn.net/patch/2318/
(11.52.10) vpnHelper: Title: [Openvpn-devel] Implement --mtu-disc for IPv6 UDP
sockets. - Patchwork (at patchwork.openvpn.net)
(11.52.24) plaisthos: will take a look later
(11.52.29) cron2: thanks
(11.52.34) cron2: it's actually very trivial
(11.53.24) cron2: (and it is a shame that no other OS has this sort of extended
socket error reporting)
(11.53.57) plaisthos: I will also try to do a patch that intorduces control
channel explicit exit notify for DCO
(11.54.07) ***cron2 likes that
(11.56.14) lev__: sorry I am late. I got feedback from Simon regarding my
change to tap-windows6 which fixes TCP problem on Windows Server 2022, he
thinks this is the way to go
(11.56.23) cron2: oh, cool
(11.56.29) lev__: so I think this could be merged
(11.56.56) lev__: (and they didn't have issues with that flag when they used it
in wintun)
(11.57.12) cron2: https://github.com/OpenVPN/tap-windows6/pull/147
(11.57.13) cron2: this one?
(11.57.24) lev__: yes
(11.57.49) lev__: (I can ask him to comment there, too)
(11.58.55) cron2: that would be good
(11.59.12) cron2: I'm glancing at the change, and it's bigger than "just a
flag", so I need to have a good stare
(11.59.54) cron2: it removes quite a bit of code
(12.00.06) cron2: (which can be a good thing :) )
(12.01.44) lev__: yeah, it has removed the code which keeps track of NBLs
(12.02.05) cron2: what is our tap packaging version scheme? Like, there is a
.zip file for downloading etc - is this named "9.24.7" or "601"?
(12.02.12) lev__: now we pass this flag to NDIS and free NBL in place
(12.03.25) lev__: not sure, but I would go with 9.24.8 or 9.25
(12.04.14) cron2: this more about "what goes into the filename when packing for
download" :-) - I'm fine with 9.24.7 otherwise
(12.04.20) cron2: (your patch bumps from 9.24.6 -> 9.24.7)
(12.05.15) lev__: ah right, well this is not that trivial change so something
needs to be bumped
(12.05.34) cron2: something needs to be bumped always on driver re-release
(12.05.43) cron2: mattock: already gone?
(12.06.08) cron2: so the question is not "if" bump, but "what to bump"
(12.06.23) cron2: if .6->.7 is good with packaging, it is good for me
(12.08.54) cron2: so...
(12.08.55) lev__: that driver hasn't got much love last years, no dedicated
maintainer
(12.09.56) cron2: before that problem came up, there was no real need
(12.11.21) cron2: anyway, I'll see that I can have a close look, and if Simon
can comment in the PR, that would be great
(12.11.34) cron2: and I'll grab mattock regarding openvpn-build and version
numbers needed
(12.12.34) cron2: anything else on 2.6?
(12.12.39) cron2: or on ipv6 to community?
(12.14.30) plaisthos: not from my side. I still have a lot of stuff I want to
do but most is not 2.6
(12.17.14) cron2: then let's conclude the meeting, and return to work :-)
(12.20.13) d12fk: aye and bye
(12.20.51) dazo: ciao!
(12.26.41) lev__: arividerchi
(12.27.13) ordex: bye bye
(12.27.29) MaxF: bye
(12.30.53) plaisthos: MaxF: the tls-crypt-v2 changes are already commited now
but maybe you still want to have a look as FoxIt was traditionally heavily
invested in that
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
