Here's the summary of the IRC meeting.



Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 7th August 2019
Time: 11:30 CEST (12: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, ordex, plaisthos and rozmansi participated in
this meeting.


Talked about some buildslave failures. Ubuntu 14.04 failure was due to
too old cmocka, which was removed, and the build is fine now. Ubuntu
16.04 fails because it tries to connect to the OpenVPN server using IPv6
transport and there's no IPv6 connectivity in its network. Mattock will
try to fix this soon. Some of tincantech's buildslaves are failing as well.


Gave https://github.com/OpenVPN/tap-windows6/pull/94 the final approval
and merged it. It will make it to the HLK tests.


Talked about progress on various patchsets. There are SITNL cleanup
patches on the list which cron2 intends to work on "soon". Ordex has
been cleaning up the VLAN patchset to make it easier to review.
Plaisthos is rebasing the async-connect patches.

Plaisthos found a corner-case with empty username in "write
auth-token-gen to be based on HMAC ..." patch (4/7) and is fixing it.


Discussed the still failing E2EPerf HLK test. Rozmansi was able to make
the test pass in a virtualized environment which points to some local
problem in mattock's HLK lab. It is likely that (test/message) traffic
gets redirected to a wrong interface which makes the test fail. Mattock
will check things such as:

- Routes
- Default routes
- Routing metrics
- Per-interface DNS settings

Rozmansi will send the logs for his successful E2EPerf run, plus related
interface, routing, etc. data to mattock. This should help mattock
resolve this final test problem.


Full chatlog attached.
(12:29:57) L'argomento di #openvpn-meeting è: Next meeting 4/July/2019 at 20:00 
CEST.  Agenda at https://community.openvpn.net/openvpn/wiki/Topics-2019-06-26
(12:29:57) L'argomento per #openvpn-meeting è stato impostato da 
dazo!~freenode@openvpn/corp/developer/dazo a 12:33:36 su 26/06/2019
(12:30:03) mattock: good day folks
(12:30:11) lev__: hello
(12:32:00) rozmansi [sid334387@gateway/web/irccloud.com/x-fozktbjitwtidmpa] è 
entrato nella stanza.
(12:32:05) rozmansi: hi
(12:33:22) mattock: anyone else present?
(12:33:31) ordex: yup
(12:33:36) mattock: hi ordex!
(12:33:38) lev__: btw rozmansi I just made ring buffers work with shared memory 
(12:33:39) ordex: cron2 was around too I think
(12:33:41) ordex: hi!
(12:33:46) ordex: dazo won't make it apparently
(12:33:49) ordex: plaisthos: here ?
(12:34:05) rozmansi: lev__: excellent! any performance benchmarks yet?
(12:34:06) lev__: rozmansi: so far for ovpn3
(12:35:12) ordex: mattock1: how was your vacation? :)
(12:35:26) rozmansi: lev__: you did notice that spin-loops were redesigned in 
our client? The old 50ms one incurred significant CPU/battery hit.
(12:35:55) lev__: rozmansi: I tried once with my early implementation and got 
about the same results as before, but I don't blame ring buffers since the 
bottleneck could be in our (proprietary) backend
(12:36:28) lev__: rozmansi: ah, no. I still use spin-loop for 50ms and then 
(12:36:53) cron2: ho
(12:37:04) mattock: ordex: I managed to avoid work quite well, which I like :D
(12:38:00) lev__: rozmansi: you mean this one? 
(12:38:01) vpnHelper: Title: tun: windows: spin for only a millisecond/80 · 
WireGuard/wireguard-go@b401012 · GitHub (at github.com)
(12:38:12) ordex: mattock1: :D
(12:38:15) mattock: rozmansi: btw thanks for trying out e2eperf - I'm pretty 
sure I'm having a local issue that makes this particular test confused 
(12:38:43) mattock: ...more on that later
(12:38:50) rozmansi: lev__: yes.
(12:39:51) ordex: btw we have a number of builders complaining most of the 
times we launch a test - any chance to fix those ?
(12:40:16) cron2: are the ubuntus still failiung on the v6 connects?
(12:40:18) ***dazo is here ... manage to rearrange a few things
(12:41:03) mattock: cron2: I have not done anything on them, except maybe 
disable the v6 tests to reduce spam (can't recall)
(12:41:25) cron2: mattock1: no, you haven't (= it's still spamming), but please 
reenable working v6
(12:41:56) ordex: I think we still have some cmocka failure
(12:42:00) ordex: at least one
(12:43:33) cron2: that is tincantech
(12:43:44) ordex: ubuntus have also 4a failing with : ./t_client.sh:  OpenVPN 
did not initialize in a reasonable time
(12:43:54) ordex: at least the 16.04 instance
(12:43:59) mattock: let me check the situation
(12:44:31) ordex: 
 << this one is failing on cmocka
(12:44:34) mattock: yeah, 16.04 is correct
(12:44:34) ordex: is this tincantech's ?
(12:44:39) mattock: no, it is mine
(12:44:44) ordex: ok
(12:44:52) mattock: let me try to fix 14.04 - "should be easy"(tm)
(12:45:10) ordex: it's complaining of some unknown types
(12:45:14) ordex: related to cmocka
(12:45:41) plaisthos: ordex: yes
(12:45:57) ordex: test.c:45:29: error: array type has incomplete element type 
const struct CMUnitTest tests[] = { << this is the actual error
(12:45:59) cron2: ordex: 4a is --proto udp6
(12:46:03) ordex: cron2: ah ok
(12:46:09) ordex: so related to what you were saying before
(12:46:11) ordex: okok
(12:46:53) cron2: ordex: tincantech's is the one that fails the dummy interface 
(12:46:58) cron2: (this got me confused)
(12:47:11) ordex: yap, right
(12:47:35) ordex: for that one I don't know yet what is going wrong, but that 
can be checked last
(12:48:50) mattock: so, would this CMUnitTest thing on 14.04 be an issue in the 
tests, or in cmocka version?
(12:49:50) ordex: likely the latter
(12:50:00) ordex: because it works on newer ubuntus
(12:50:02) cron2: that smells like cmocka version... so possibly just removing 
libcmocka altogether might fix it (as in "we do not bothre")
(12:50:18) ordex: cron2: that would prevent running the unit tests, no ?
(12:50:32) ordex: but I guess we still run t_client.sh
(12:51:34) mattock: I'll get rid of cmocka then
(12:52:19) cron2: ordex: yes, it would only affect cmocka based tests
(12:52:33) ordex: ok
(12:52:46) ordex: sounds good
(12:55:21) mattock: gone for good
(12:55:55) mattock: triggered a rebuild on 14.04
(12:56:52) mattock: I'll check the logs on 16.04
(12:57:03) mattock: but that can happen outside of precious meeting time
(12:57:17) mattock: so, what have you guys done during my absence? :P
(12:58:29) cron2: we've been waiting for you :-)
(12:58:43) rozmansi: :)
(12:58:49) cron2: but besides this, we've been waiting for dazo
(12:59:02) rozmansi: I did this: https://github.com/OpenVPN/tap-windows6/pull/94
(12:59:02) rozmansi: any chance to get it merged before WHLK?
(12:59:03) cron2: and patch respins from plaisthos
(12:59:04) vpnHelper: Title: Remove NCF_HAS_UI flag from Characteristics by 
rozmansi · Pull Request #94 · OpenVPN/tap-windows6 · GitHub (at github.com)
(12:59:06) dazo: should I run? :-P
(12:59:16) cron2: dazo: hah! :-)
(12:59:41) mattock: rozmansi: no problem at my end, I've started from scratch 
and will make E2EPerf test pass before I run any other tests
(12:59:55) mattock: so merging stuff is still quite doable
(13:00:00) cron2: rozmansi: it looks good to me, everyone else said "yeah, this 
looks reasonable"; so I'm fine.  I think mattock1 wanted to merge it anyway 
(13:00:11) mattock: I can do it now
(13:00:33) plaisthos: Yeah, I think I will do the new patches this week
(13:00:46) rozmansi: thanks. eduVPN project has a potential customer that use 
HP Envy laptops exclusively and cannot use OpenVPN without this.
(13:01:14) mattock: done
(13:01:15) cron2: dang
(13:01:36) cron2: I was about to merge it and then write to the channel "no you 
can't, I've already merged it!" but logging in took too long
(13:01:43) cron2: I saw the button disappear :-)
(13:01:43) mattock: lol!: )
(13:02:02) cron2: anyway
(13:02:50) cron2: we have a bunch of SITNL cleanup patches on the list, that I 
intend to work on "soon".  ordex wants to move forward to other larger blocks - 
vlan, async-cc.
(13:02:58) cron2: syzzer reappeared and disappeared again
(13:03:08) cron2: that's about what happened :-)
(13:03:28) mattock: ok, so not that much :)
(13:03:32) cron2: oh, there's two ACKed patches in patchwork that I need to 
take care of
(13:03:44) cron2: iservice-for-tap-open and openssl 1.1 stuff
(13:08:08) ordex: :)
(13:08:36) ordex: the sitnl cleanup patches should just need a "light" review - 
but you never know :D
(13:08:50) lev__: cron2 we need to wait with iservice patch, since latest 
wintun changed security model and API and we no longer need to be privileged to 
open device
(13:08:58) ordex: in background I started working on reorganizing the vlan 
patches so that they are easy to review/test/merge. MEanwhile I am witing for 
plaisthos to rebase his async-connect patches
(13:09:18) cron2: lev__: a-ha.  So I shall not merge the acked v6 then?
(13:09:29) plaisthos: ordex: hu?
(13:09:41) lev__: otoh, buffers registration should be done by privileged 
process, but we do not have that yet in openvpn2
(13:09:42) plaisthos: do they need rebasing?
(13:09:57) lev__: yep, do not merge 
(13:09:59) ordex: plaisthos: yes, this is what I Asked on #openvpn-devel 
yesterday, no? that message you said you have read :D
(13:10:04) plaisthos: ah
(13:10:13) ordex: [2115.46]<@ordex> plaisthos: when you've got a chance, could 
you please rebase your client-connect code on top of latest master and let me 
know the name of the brain I can pull from ?
(13:10:13) ordex: [2116.00]<@ordex> I'd like to move on with the review, but I 
also don't want to break your code by doing the rebase myself
(13:10:13) ordex: [2116.02]<@ordex> thanks !
(13:10:15) ordex: :D
(13:10:16) cron2: lev__: can you send a followup mail on the list to explain 
what I should do?  (So we have it on the list, otherwise it looks a bit funky 
"there is an ACK but no merge, why?  does cron2 not like lev__ anymore?" :-) )
(13:10:25) plaisthos: should I also send them to list then?
(13:10:26) ordex: no rush - as I have other things to follow anyway
(13:10:26) cron2: ordex: there is no brains
(13:10:46) lev__: will do
(13:10:51) ordex: plaisthos: I don't think so for now - let me first see if I 
have comments on the actual code, unless rebasing changes the patches a loot
(13:14:42) ordex: cron2: there never was one
(13:14:50) ordex: !!
(13:15:13) plaisthos: okay rebasing went with only a minimal conflict in one 
(13:15:20) plaisthos: o github.com:schwabe/openvpn.git
(13:15:20) plaisthos:  + b19e26b7...9071028d deffered_client_connect_rebase -> 
deffered_client_connect_rebase (forced update)
(13:16:30) ordex: plaisthos: ok, so I use this branch: 
deffered_client_connect_rebase ?
(13:19:55) plaisthos: yeah
(13:20:36) cron2: plaisthos: you were working on a "take dazo's comment into 
account plus bugfix" of the "write auth-token-gen to be based on HMAC ..." 
patch (4/7).  Any news on this?
(13:20:58) cron2: since dazo is back we can then push him to review and ACK :)
(13:21:09) plaisthos: found a corner case bug with empty username that I want 
to fix
(13:22:08) plaisthos: but I am confident to do that this week
(13:22:49) cron2: cool
(13:23:39) mattock: I have one question about Windows you guys might have a 
clue about
(13:23:49) mattock: regarding the final failing HLK test - E2EPerf
(13:24:24) mattock: let me know if I may proceed without interrupting something 
else :)
(13:24:50) rozmansi: go ahead
(13:24:56) mattock: ok
(13:25:40) ***cron2 listens :)
(13:26:02) mattock: so, rozmansi was able to make E2EPerf pass in Virtualbox, 
which means there's some local issue in my test setup that this particular test 
(13:26:26) mattock: one option is that (some of the) traffic goes into the 
wrong interface
(13:26:59) mattock: any ideas how such a thing could happen?
(13:28:02) mattock: rozmansi already suggested that maybe traffic gets 
redirected to the s.c. MessageDevice network (=communication with HLK 
controller) because that's faster (which it is)
(13:28:10) mattock: well actually
(13:29:06) rozmansi: one think I remembered later... mattock1, are you using 
tap or tun for tunnels?
(13:29:10) mattock: tap
(13:29:22) mattock: earlier (=in EC2) I was using tun
(13:29:22) rozmansi: ok, I did too, so this is not the case.
(13:29:54) mattock: I just recalled some routing metric discussions related to 
Windows, which is why I asked
(13:30:18) rozmansi: as far as I understood the test network should be 
completely isolated from message network
(13:30:53) mattock: and it actually is now - the HLK client and support machine 
attached directly with a cable
(13:31:07) mattock: with statically configured interfaces
(13:31:12) mattock: and openvpn traffic goes on top of that
(13:31:14) rozmansi: oh, yes... Windows do have a service that monitors network 
traffic and tries to adjust metrics to redirect traffic to faster route.
(13:32:10) mattock: so, if it thinks it can route traffic through to <a> 
through 10Gbps interface <n>, it will choose that over interface <m> which is 
only 1GBps, right?
(13:32:39) rozmansi: and openvpn and traffic channel have separate IP address 
space, right? And no packet forwarding anywhere, right?
(13:33:00) rozmansi: mattock1: right
(13:33:10) mattock: yes, that is the case, but I will have to double check 
those in case there are some odd defaults
(13:33:13) cron2: mattock1: windows should only do that if there are multiple 
(13:33:28) mattock: yeah, I will definitely need to start looking at metrics 
and routes and all that
(13:33:30) cron2: (like, lan+wifi in the same 192.168.x segment, or two default 
(13:33:51) rozmansi: mattock1: I didn't set any routes in may openvpn setup. 
Just p2p.
(13:34:26) mattock: rozmansi: the openvpn config is as documented here: 
(13:34:27) vpnHelper: Title: HLKTesting – OpenVPN Community (at 
(13:34:34) mattock: but anyways, I can move forward with this
(13:34:51) mattock: good to know the test _can_ pass and that this is probably 
a problem with packets going to a wrong place
(13:35:04) rozmansi: mattock1: I can send you my .conf files and describe my 
setup again. I didn't even use separate NIC and cable/switch to deliver VPN 
(13:35:11) mattock: I did start looking at packet captures, but did not (yet) 
notice anything wonky
(13:35:23) rozmansi: mattock1: yes, this is definitely _not_ a driver issue.
(13:35:25) mattock: rozmansi: if you can also send the logs for your successful 
run that'd help
(13:35:54) mattock: plus whatever routing/interface info you can get (e.g. with 
(13:36:06) mattock: DNS servers set for the interfaces, etc.
(13:36:28) mattock: anyways, is there anything else for today?
(13:36:32) mattock: we're 66 minutes in
(13:36:49) rozmansi: mattock1: sure, will fire up VPCs and send you 
(13:37:08) mattock: thanks!
(13:39:30) mattock: oh, and mini-hackathon next Fri
(13:39:37) mattock: btw. yes, I will be joining Trento
(13:39:46) mattock: I'm trying to soften up $wife to join
(13:40:00) mattock: she'd like to go to Italy, but she claims it is cold in 
Trento in November
(13:40:19) mattock: :D
(13:40:37) ordex: :D
(13:40:44) ordex: witht he latest climate changes you never know !
(13:40:46) mattock: ordex: any comments on the temperature/humidity/rain?
(13:40:53) ordex: but yes, "might" start getting colder by then
(13:41:09) mattock: daytime temperature being reasonable still I guess?
(13:41:16) mattock: 15+ celsius?
(13:41:26) rozmansi: mattock1: funny... my $wife wanted to go too. after trying 
to explain I will be on totally different planet in Trento, she didn't took it 
so well. :(
(13:41:36) ordex: I'd say between 10 and 15 yes, but we better check the 
forecast :D
(13:41:43) ordex: it's gonna be my fiorst november here in a while
(13:41:45) mattock: ordex: ok
(13:41:56) ordex: rozmansi: :D
(13:41:59) mattock: rozmansi: yeah, that is a challenge
(13:42:15) mattock: my $wife can venture around by herself, plus she'd have one 
week of vacation left
(13:42:31) mattock: I'd like to stick around for a bit longer anyways
(13:42:44) mattock: I'll report when I have convinced her, or failed doing so :)
(13:43:11) mattock: ok writing summary, will send soon

Attachment: signature.asc
Description: OpenPGP digital signature

Openvpn-devel mailing list

Reply via email to