And the chatlog, as promised...

Hi,

Here's the summary of today's IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-devel on irc.freenode.net
Date: Monday 21st Sep 2015
Time: 20:00 CEST (18:00 UTC)

Planned meeting topics for this meeting were here:

<https://community.openvpn.net/openvpn/wiki/Topics-2015-09-21>

The next meeting has been scheduled to two weeks from this meeting:

<https://community.openvpn.net/openvpn/wiki/Topics-2015-10-05>

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

<http://www.timeanddate.com/worldclock>

SUMMARY

cron2, gava100, syzzer, mattock and plaisthos participated in this meeting.

---

Discussed Windows builds. Agreed that --disable-debug should be removed,
so that debugging can be enabled using a runtime option. This should not
affect performance in any significant way. Mattock made this change to
openvpn-build during the meeting, so that all future OpenVPN Windows
builds will have debugging capabilities.

--

Discussed the "Added two feature to Network Address Translator" patchset:

<http://thread.gmane.org/gmane.network.openvpn.devel/10047>

The NAT code adds quite a bit of code, which could bring with it
security vulnerabilities. For example FTP NAT code in other products has
historically had security issues. Cron2 will review the patches a bit
more before any decisions are made. Rafael will split the patch into two
to ease review and merging.

--

Discussed the "​fix unaligned access to TCP MSS" patch:

<http://thread.gmane.org/gmane.network.openvpn.devel/10047>
<https://community.openvpn.net/openvpn/ticket/497>

Syzzer gave the patch an ACK.

--

Discussed the "get_default_gateway_ipv6() for Windows (10/10)" patch:

<http://thread.gmane.org/gmane.network.openvpn.devel/10085>

The patch drops support for building for Windows XP, so it can only be
merged into Git "master", not 2.3.x.

Cron2 has tested the patch somewhat and has a few potential testers
waiting. Special Windows builds with this patch will be built by mattock
soon.

--

Discussed merging the "​redirect-gateway ipv6" patch to 2.3.x:

<http://thread.gmane.org/gmane.network.openvpn.devel/10086>

Cron2 will provide a patch against 2.3 and send it to the devel list.

--

Discussed the "strdup() return checks" patch:

<http://thread.gmane.org/gmane.network.openvpn.devel/10046>
<https://community.openvpn.net/openvpn/ticket/600>

Syzzer will provide two patches to replace this one.

--

Discussed merging the "control packet MTU increase" patch to 2.3:

<http://thread.gmane.org/gmane.network.openvpn.devel/9841>
<https://community.openvpn.net/openvpn/ticket/545>

Syzzer ACKed merging the patch to 2.3.

--

Review of the "​fix privilege dropping if first connection attempt
unsuccessful" patch had to be postponed, because it was getting too late.

---

Full chatlog has been attached to this email.


--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock
(20:57:50) mattock: okay, almost meeting time
(20:59:58) syzzer: yep!
(21:01:43) mattock: cron2: you here?
(21:02:15) cron2: yep
(21:02:23) cron2: *I* was here all day :-)
(21:02:42) cron2: so what did you see from the questions I asked at 17:20?
(21:03:54) mattock: probably none
(21:04:01) mattock: can you copy and paste?
(21:04:21) cron2: query...
(21:05:09) cron2: pasted :)
(21:05:56) mattock: cron2: I'll paste your paste to ticket so that I don't 
forget
(21:06:02) mattock: I'll try to build the installers tomorrow
(21:06:16) cron2: thanks
(21:06:23) cron2: ok, let's go :)
(21:06:38) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2015-09-21
(21:06:40) vpnHelper: Title: Topics-2015-09-21 – OpenVPN Community (at 
community.openvpn.net)
(21:06:46) mattock: some kind soul prepared that agenda while I was missing
(21:06:54) ***cron2 <-
(21:07:06) cron2: it's the agenda from two weeks ago, with small updates
(21:07:52) cron2: first item is on you anyway :-) - in my windows build 
environment (which was set up some 2 years ago according to your instructions), 
I noticed that the binaries get built with "configure --disable-debug" - which 
breaks --show-gateway
(21:08:24) cron2: can you check whether this is still so, and if yes, please 
remove the --disable-debug? It does not make much size difference, but when 
debugging the new route-gateway-ipv6 stuff, I need --show-gateway
(21:09:02) mattock: ok so topic #1 is talking about the Git "master" -based 
installers, right?
(21:09:20) cron2: yes
(21:09:29) mattock: ok, -> TODO
(21:09:40) cron2: well, windows installer build system in general, that is
(21:10:07) cron2: I do not think we should ever build with --disable-debug, as 
it, uh, disables debugging functionality :-)
(21:10:34) mattock: how much does debugging slow things down?
(21:10:50) mattock: do we have like tons of #ifdefs with debugging stuff?
(21:11:12) syzzer: stuff like dmsg() calls are not compiled in
(21:11:21) syzzer: but we mostly use msg() anyway
(21:11:25) cron2: we do have like tons of #ifdef ENABLE_DEBUG calls :-)
(21:12:20) cron2: but most of it is not performance impacting, like the 
--show-gateway functionality - that is called once at connection setup and does 
a few printf()s
(21:13:26) mattock: ok so enabling debug on stable installers will not kill 
performance
(21:13:32) mattock: I'm fine with it if you are
(21:14:03) syzzer: we enable it on most other platforms already afaik
(21:14:16) cron2: the performance critical stuff is only enabled if you "really 
turn it on"
(21:14:24) cron2: #ifdef ENABLE_DEBUG
(21:14:24) cron2: if (check_debug_level (D_EVENT_WAIT))
(21:14:24) cron2: show_wait_status (c);
(21:14:24) cron2: #endif
(21:14:27) cron2: like this
(21:14:33) mattock: it seems I need to turn it on by default in openvpn-build, 
because my buildtest thing clones openvpn-build anyways
(21:14:46) mattock: ah yes, so runtime option
(21:14:54) mattock: makes perfect sense
(21:15:02) mattock: I think I'll fix this right now
(21:15:28) cron2: thanks :)
(21:15:49) cron2: (if you really need to squeeze out the last few bits, 
--enable-small --disable-debug can be done, but not on a generic windows build)
(21:17:17) mattock: 
EXTRA_OPENVPN_CONFIG="${EXTRA_OPENVPN_CONFIG:---enable-password-save 
--disable-debug --disable-snappy}"
(21:17:26) cron2: this :)
(21:17:34) mattock: so removing --disable-debug will be enough?
(21:17:39) mattock: no need to --enable-debug
(21:17:44) cron2: yes
(21:21:36) mattock: let's move on while I commit the change
(21:21:47) mattock: uh, T-shirts
(21:21:54) cron2: haha :)
(21:21:54) mattock: I wonder who will order those?
(21:22:03) mattock: I've heard of no volunteers
(21:22:07) mattock: :P
(21:22:28) syzzer: haha
(21:23:13) syzzer: we could pick up the strdup() stuff while you commit the 
change :)
(21:23:34) cron2: I think we'll need to find a fair selection criteria, like 
"number of lines in #openvpn-devel in relation to commit messages" or so :)
(21:24:12) cron2: syzzer: yep :) - I think strdup() needs to just go out and be 
replaced by string_alloc(...,NULL) - done
(21:24:31) cron2: one might argue about the beauty of certain code parts 
afterwards, but that is the proper fix
(21:24:50) gava100 [~circuser-@201.48.114.241] è entrato nella stanza.
(21:24:50) syzzer: yes, I agree with that part
(21:24:55) mattock: ok, done
(21:25:00) gava100: Hello All,
(21:25:04) cron2: (the windows strdup() bit might be left in, as it's if (... 
NULL) checked anyway
(21:25:08) syzzer: but some of this code is just weird...
(21:25:35) cron2: some of this smells like "James coded it, it was perfect, and 
one of us optimized/hardened/tweaked it" :)
(21:25:56) syzzer: yes, most likely :)
(21:25:58) gava100: Please I'd like to hear a feedback from you guys regarding 
the features for openvpn NAT.
(21:26:40) cron2: gava100: well. I skimmed the code, and the amount of extra 
lines it brings is fairly huge
(21:26:56) cron2: (since it needs to deal with shifting sequence numbers, which 
we do not have anywhere else)
(21:31:33) cron2: so it's really a trade off - do we want to maintain the NAT 
translation code at the extent of lots of extra code that needs really careful 
review (enough products have had security issues in FTP translation code - 
like, what happens if the string after translation is too big for the MTU 
because someone is playing tricks on us?)
(21:32:35) gava100: good point. :-)
(21:32:53) cron2: I need to look more closely into the description of your use 
case again and see whether I can find a nice way to solve your use case without 
adding code :-)
(21:33:10) cron2: it is still sitting in my mailbox "TODO queue"
(21:33:20) gava100: great!!! Thx!!!
(21:34:46) cron2: (besides: plaisthos removed the #ifdef CLIENT_NAT, so you 
might want to rebase :-) )
(21:35:29) gava100: ok. I'll do that and should I send the patch again?
(21:40:04) cron2: gava100: please
(21:40:29) gava100: and despite the FTP NAT implementation, how about the 
"client-ip" parameter on the client-nat option? What did you think? It's a easy 
and small change.
(21:41:17) cron2: gava100: I have not fully understood those yet, but that 
might be due to my unfamiliarity with --client-nat in general. Need to read up 
on it and then I'll comment
(21:41:35) cron2: but smaller patches that do not involve moving around buffers 
are much easier to review :)
(21:43:01) gava100: all right, I'll send 2 patches then. The first one for the 
client-ip and the other one with the FTP NAT, ok?
(21:44:52) cron2: gava100: thanks!
(21:45:32) gava100: u r welcome!!!
(21:46:51) mattock: next topic?
(21:47:20) cron2: Tim has been postponed, but we have on record that Dazo will 
review in Delft (he'll arrive Thursday afternoon, so has all of Friday morning 
to get this done :) )
(21:47:32) cron2: some Gert Doering has been busy and has sent quite a bit of 
stuff!
(21:47:58) TimSmall [~t...@ipv6test5.plus.com] è entrato nella stanza.
(21:48:11) ***cron2 looks at syzzer for the MSS bits, and at mattock for the 
get_default_gateway_ipv6() bit
(21:49:08) ***syzzer wakes up
(21:49:17) syzzer: MSS, let me see...
(21:49:18) mattock: looking at 
http://thread.gmane.org/gmane.network.openvpn.devel/10085
(21:49:19) vpnHelper: Title: Gmane Loom (at thread.gmane.org)
(21:50:35) mattock: I'm currently building with "get_default_gateway_ipv6(): 
Win32 implementation using GetBestRoute2()" patch
(21:51:57) mattock: I cannot really comment on the code, but dropping WinXP in 
"master" is fine
(21:52:18) mattock: we should probably try to get our users to test the special 
installers which I'm hopefully able to produce
(21:52:24) mattock: (so far no build errors)
(21:52:35) cron2: which ones has it built already?
(21:53:16) cron2: I only built an openvpn.exe for 32bit, as I have no real 
proper "build installer" environment, just a leftover test tree that can build 
.exe :-)
(21:54:01) cron2: and I might come up with a tester for these installers as 
well - two people independently asked me for "we need the overlapping 
route/gateway functionality!", so, this might actually get some excercise :-)
(21:54:42) cron2: (I *did* test this, but use cases vary so much that I could 
only test a few cases, and even that took about a day, across 5 BSDs, 2 MacOS 
versions, Solaris, 2x Linux and Windows...)
(21:54:52) mattock: yeah
(21:55:17) mattock: the buildtest thing builds both 32-bit and 64-bit installers
(21:55:29) mattock: http://build.openvpn.in/downloads/snapshots/
(21:55:37) cron2: cool
(21:55:41) mattock: they should pop in there
(21:55:59) cron2: if you install it and run "openvpn --show-gateway", will it 
print something?
(21:56:06) mattock: there they are: http://build.openvpn.in/downloads/snapshots/
(21:56:07) cron2: (that is the "--disable-debug" bit :) )
(21:56:27) mattock: well it should have fetched latest openvpn-build which does 
not have --disable-debug
(21:56:30) mattock: I'll check just in case
(21:57:05) mattock: ok, it did not update openvpn-build
(21:57:11) mattock: retriggered the builds after a rebase
(21:57:12) ***cron2 has no access to build.openvpn.in...
(21:57:17) mattock: oops
(21:57:20) mattock: replace with .net
(21:57:35) mattock: http://build.openvpn.net/downloads/snapshots/
(21:57:36) vpnHelper: Title: Index of /downloads/snapshots/ (at 
build.openvpn.net)
(22:01:28) syzzer: cron2: the MSS bit looks good to me, although I do not 
really like the casts in the dmsg()...
(22:02:40) cron2: syzzer: what would you suggest? printf() format characters 
and "strict bit length" integers never truly get along well... and an (int) 
will always be long enough here, and %d=int, so "well defined"
(22:03:38) cron2: one could use "int" for mssval and maxmss, but that would 
make the patch larger, achieving the same thing
(22:03:54) syzzer: the alternative is using PRIu16, but I agree that this won't 
do any harm
(22:03:55) ***cron2 didn't introduce the (int), btw :)
(22:04:18) syzzer: yes, I noticed this was already there :)
(22:04:25) syzzer: to I'm ok with the change itself
(22:06:04) cron2: (I think C expands this to (int) anway... so actually getting 
rid of it might be fine :) - looking at my _inttypes.h here, I find that PRIu8 
to PRIu32 all map to "u")
(22:07:09) cron2: so, ACK or change?
(22:09:48) syzzer: hmm, no similar surrounding code
(22:10:09) syzzer: so let's fix this too :)
(22:11:32) syzzer: should I reply on the list, or will you send a v2?
(22:12:16) cron2: what is it that you want to see? I'm actually not very happy 
about using PRIu16 as I find that much uglier than (int)
(22:12:55) cron2: (especially given that "int" is never less than 16 bits, so 
the cast is totally safe)
(22:13:30) syzzer: is (int) guaranteed to be more than 16 bits?
(22:14:52) cron2: I'm not absolutely sure if there is an embedded 8 bit system 
somewhere that uses int=8bit, but everything reasonable (like, "turbo C on dos 
3.11 and later") has 16 bits or more
(22:15:20) cron2: but everything we'll ever be able to run on is
(22:15:52) mator: evening. got my real sparc (v215 server) with linux back 
online
(22:16:43) cron2: mator: hey :-) - and, does it behave?
(22:17:41) cron2: mattock1: so the 767e4c56be snapshot has the --show-gateway 
code?
(22:18:23) syzzer: sorry - needed to help $gf in the kitchen. back now.
(22:19:39) mattock: cron2: just a se
(22:19:40) mattock: c
(22:20:16) mattock: 
http://build.openvpn.net/downloads/snapshots/openvpn-install-20150921191336-767e4c56be-i686.exe
(22:20:16) mattock: 
http://build.openvpn.net/downloads/snapshots/openvpn-install-20150921191336-767e4c56be-x86_64.exe
(22:20:19) mattock: those should have it
(22:20:20) syzzer: my OCD tells me to use "The Right Specifier", but if you 
prefer (int), I'll just ACK and we'll be done with it :)
(22:20:34) cron2: syzzer: we currently use PRI[udi] exactly in one place, which 
is fairly new code...
(22:20:47) syzzer: heh, probably my code :p
(22:20:56) cron2: nah, lev__, but you reviewed it :-)
(22:21:05) cron2: (float)
(22:21:11) syzzer: ah
(22:21:54) ***cron2 prefers (int) :-) but I'm open to discuss this as part of 
"the new coding style" in Delft
(22:22:24) syzzer: ... and it's a dmsg() call anyway, and who would even build 
production binaries without --disable-debug... ;)
(22:22:28) cron2: mattock1: cool. Do you have a VM at hand for a quick test?
(22:22:31) cron2: lol
(22:22:40) cron2: syzzer: do you?
(22:23:16) syzzer: ACK sent
(22:23:27) cron2: \o/ I can close a ticket!
(22:23:29) TimSmall: cron2: FWIW, I think we could go so far as to say 
everything that openvpn will ever run on will have int >= 32 bits, and also it 
must be at least 16 bit according in ICO C 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=34
(22:23:39) syzzer: no, I build without --disable-debug too
(22:23:48) mattock: argh
(22:24:01) mattock: I will need to rebuild _again_
(22:24:05) mattock: just a sec
(22:24:40) mator: cron2, going to check it tomorrow
(22:24:58) cron2: TimSmall: yeah, every *reasonable* platform should be totally 
sane in this regard (like, "memory model requirements" and such), but I 
wouldn't risk my life on "there is no weird 8-bit C compiler anywhere" :)
(22:25:13) cron2: it won't be an ISO C compiler, but maybe K&R 77 or so...
(22:25:16) syzzer: TimSmall: ah, so uint16_t will always fit with %u
(22:25:21) syzzer: that's useful to know
(22:25:34) cron2: mattock1: what happened?
(22:26:05) cron2: mator: can you comment into the trac ticket, then? I'll merge 
the code ASAP (master+2.3), but having that feedback would also be nice
(22:27:21) mattock: well, it was still using the standard openvpn git repo
(22:27:33) mattock: I scrapped the whole tmp-directory
(22:27:46) mattock: now it has no option but to refetch from the correct URL
(22:28:14) cron2: haha, your build system really likes to do that :-) - "yeah, 
I can see that you want me to use git, so I fetch git, build a tar from that, 
ignore it, fetch the 2.3.8 tar ball, and build *that*"
(22:29:25) mattock: well, that one is Alon's buildsystem with minor tweaks from 
me and pekster
(22:29:40) mattock: although _this_ buildsystem is a wrapper on top of that 
buildsystem
(22:29:42) cron2: yes, but since you took over, it is all YOUR fault now :)
(22:29:54) TimSmall ha abbandonato la stanza (quit: Ping timeout: 272 seconds).
(22:30:03) mattock: not all, but there are not that many other people to blame 
nowadays :P
(22:30:34) cron2: yeah, we need to do something about that. Like, T-Shirts!
(22:30:37) mattock: and as we know, the most important thing is to know "who's 
fault is this?" :)
(22:30:43) ***cron2 runs
(22:32:00) mattock: how about 
http://thread.gmane.org/gmane.network.openvpn.devel/10086 ?
(22:32:01) vpnHelper: Title: Gmane Loom (at thread.gmane.org)
(22:32:25) cron2: the question on that one basically is
(22:32:46) plai: Hello from dublin
(22:32:50) cron2: "we have '--redirect-gateway ipv6' in 2.4 and 3.x now, but 
not in 2.3, so people cannot use it"
(22:32:53) ***plai is on vacation this monday
(22:32:57) cron2: plai: hello to dublin :-)
(22:33:12) plai: cron2: for the trac ticket, i don't have my login ready
(22:33:20) plai: but it is consistent on all platforms
(22:33:35) plai: openbsd just does not believe in ipv4 mapped addresses
(22:34:05) cron2: plai: no, it isn't -- "proto udp" on FreeBSD will give you a 
v6 socket, and on Linux a v4 socket - at least 22 months ago when I tested this
(22:34:11) cron2: (a server socket, that is)
(22:34:28) cron2: on OpenBSD, you're screwed anyway, but I don't care much
(22:35:14) plai: cron2: oh that
(22:35:27) plai: cron2: yeah that is due to different beavhiour of getaddrinfo
(22:35:44) TimSmall [~t...@ipv6test5.plus.com] è entrato nella stanza.
(22:35:50) cron2: yep :-) - I had all forgotten about this trac, but valdikss 
is very busy digging up stuff that we should fix
(22:36:18) plai: but I should dig up my multisocket branch again
(22:36:41) cron2: +1
(22:36:42) plai: iirc udp almost works and tcp did not work due to the "Arne 
did not understand timers in OpenVPN"
(22:36:59) cron2: now time has passed, and timers are understood!
(22:37:11) cron2: (I skimmed that patch, until time ran out)
(22:37:16) mator: cron2, it's unstable debian, and it does not have git 
installed =( going to get git first (or fetch github snapshot) and compile 
tomorrow
(22:37:25) mator: but will commend in trac ticket anyway
(22:37:35) cron2: thanks
(22:39:15) plai: I am back to vaction
(22:39:35) cron2: enjoy!
(22:39:43) cron2: so, return-from-subroutine... :-)
(22:39:51) cron2: talking about redirect-gateway ipv6
(22:40:23) ***cron2 suggests having these two keywords (ipv6 and !ipv4) in 
2.3.x as well, so people can actually use them in their configs without having 
to check "oh, this is a 2.3 client, don't"
(22:40:52) syzzer: makes sense to me
(22:40:53) cron2: there is a certain danger - "connecting over ipv6 and using 
redirect-gateway ipv6 will blow up!" - but the alternative (route-ipv6 
2000::/3) will blow up just as well
(22:41:38) cron2: blame James for introducing new keywords :-) - and FTR, 
sending "redirect-gateway ipv6 !ipv4" to an iphone will blow up openvpn there, 
as the VPN API does not believe in "you should be able to do IPv6-only!" :-)
(22:44:46) syzzer: heh, brilliant
(22:45:48) syzzer: I really don't have much of an opinion here, when it comes 
to networking, I just listen to what you and plai think ;)
(22:45:52) cron2: but anyway, this is why this is on the agenda - I'll prepare 
and send the patch, next :-)
(22:46:08) mattock: http://thread.gmane.org/gmane.network.openvpn.devel/10061 
next?
(22:46:09) vpnHelper: Title: Gmane Loom (at thread.gmane.org)
(22:46:41) cron2: let's jump one to the strdup() one - syzzer: have we covered 
this?
(22:46:54) syzzer: yes, I'm sending new patches
(22:47:01) plai: cron2: one last thing before really back to vaction
(22:47:14) plai: cron2: you might want to print an error/warning on 
redirect-gateway !ipv4
(22:47:20) plai: hm
(22:47:25) plai: on second thought not
(22:47:36) plai: redirect-gateway def1
(22:47:39) cron2: ?
(22:47:44) plai: and redirect-gateway ipv6
(22:47:52) cron2: this will do ipv4+ipv6
(22:47:59) plai: on two seperate lines will work, right?
(22:48:25) cron2: yep
(22:48:43) cron2: each redirect-gateway line will just or-in flags
(22:48:51) syzzer: one to simple replace strdup() with string_alloc(), and 
another one to add a return value check for ms_error_text(), because I don't 
fully trust all ERR-related code in OpenSSL (and our use of it) to be capable 
of handling NULL pointers
(22:48:56) cron2: but the flags will only be zeroed when allocationg the 
route-option-list
(22:49:16) cron2: so, "yes"
(22:49:19) cron2: (to plai)
(22:49:55) cron2: syzzer: where do you see a NULL pointer?
(22:50:14) syzzer: ms_error_text() can return NULL now
(22:50:58) cron2: true, both if FormatMessage() fails and if strdup() fails
(22:51:05) syzzer: ERR_load_strings() itself doesn't care and just stores the 
NULL pointer somewhere, but that means it will probably also happily return it 
to it's users
(22:51:51) syzzer: .. which might or might not be correctly handled
(22:51:52) cron2: so it's returned further upstream, not only used inside 
err_put_ms_error()?
(22:52:12) syzzer: yes, it's loaded in some error string database inside openssl
(22:52:36) ***cron2 is scared
(22:52:36) syzzer: s/database/list/
(22:53:00) syzzer: yes, I do not like it either
(22:53:30) cron2: but this is actually very easy for me :-) - "this is crypto 
stuff and if you say there should not be a NULL pointer here, I believe that" 
:-)
(22:53:48) syzzer: the annoying thing is, this is windows code that is no fun 
to test...
(22:57:54) ***cron2 mentions that the "get me routing info" API on Windows is 
actually fairly sane, as opposed to the others...
(22:58:22) mattock: syzzer: so you are going to send new strdup() patch? or 
more patches on top of that one?
(22:58:37) syzzer: two pathces to replace that one
(22:58:38) cron2: of course the netlink stuff is way more flexible, powerful, 
yadda yadda, but it's still not exactly easy to use
(22:58:58) cron2: syzzer: I'll take it in one patch as well :)
(22:59:24) syzzer: ah, fine with me too
(22:59:26) cron2: mattock1: so the thing you just built, is it The Right Thing?
(22:59:44) syzzer: just want to see at least a smoke test working
(23:00:46) mattock: cron2: actually no, lol
(23:00:51) mattock: this is due to openvpn-build though
(23:00:59) mattock: I will need to do more plumbing work
(23:01:17) mattock: openvpn-build insists on fetching the vanilla sources
(23:01:22) cron2: syzzer: understood :)
(23:02:02) syzzer: mattock1: yeah, that's quite annoying :p
(23:03:00) syzzer: but I won't complain. I have no clue how to builds 
openvpn+openssl myself without those scripts...
(23:08:02) cron2: ok, it's late :-) - I'd skip the patch from Lukas for today, 
and go to the last item - "control packet MTU increase". It has been tested by 
people on busy servers, and plaisthos has it in the Android code base, and 
nobody complained so far - so I'd suggest to cherry-pick to 2.3 as well
(23:08:33) syzzer: +1
(23:08:42) mattock: I'll have to build the special Windows installers when I'm 
less tired... all sorts of annoying little issues
(23:09:40) cron2: good night :) - I think it was quite a good meeting, after 
quite some time... next meeting in 2 weeks, getting ready for Delft in 3 weeks?
(23:10:06) mattock: yes, good idea
(23:10:13) syzzer: yes, works for me
(23:10:35) cron2: in that case - thanks, and good night :-)
(23:10:45) syzzer: (I don't particularly feel like getting into the 
windows-build-mess right now either ;) )
(23:10:50) syzzer: good night!
(23:10:55) cron2: (and mattock managed to cleverly manaeuver around the T-Shirt 
issue)
(23:11:02) cron2: sp...
(23:11:37) mattock: yeah, I indeed did
(23:11:44) mattock: good night!
(23:11:46) gava100: ok guys, thx!
(23:12:14) mattock: bye gava100!
(23:12:32) gava100: bye bye!
(23:15:10) mattock: summary away

Reply via email to