Hi, Here's the summary of the previous IRC meeting.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 18th Aug 2011 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2011-08-18> Next meeting will be announced in advance, but will probably be on the same weekday and at the same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/world clock> or with $ date -u For old summaries and instructions for joining the IRC channel/meetings look here: <https://community.openvpn.net/openvpn/wiki/IrcMeetings> SUMMARY cron2, dazo, jamesyonan, mattock and praetorian participated in this meeting. -- Discussed "community get-together" plans. Agreed that a get-together would be very useful, especially in connection with a major development event such as bootstrapping of OpenVPN 3.0 development. Some preferred postponing the event to (early) next year to allow planning for it. Also, the general consensus was that the event would take place somewhere in Europe. This may change, e.g. if enough Americans express their interest. -- Discussed the OpenVPN 2.2.2 release briefly. Agreed that the Windows build should include the recently updated pkcs11-helper library. Also, there's one bug that has to be fixed before 2.2.2 release: <https://community.openvpn.net/openvpn/ticket/126> -- Discussed dazo's heroic merge from James' SVN repository to the temporary svn-merger branch: <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=e47fb603ed721bb718495e6f8ed42ec134da2f98> <https://community.openvpn.net/openvpn/wiki/Topics-2011-08-18#SVNmerger> Cron2 had written one patch against svn-merger branch prior to the meeting. He also fixed one bug in the code during the meeting. Jamesyonan gave the merge his ACK after cron2's fixes. -- Discussed status of public test server briefly. In a nutshell, the original FreeBSD test server is not more, but ecrist should have an unconfigured replacement ready for us. If not, praetorian promised to setup a Linux VM for the same purpose. Also, at the moment none of the buildslave VMs are up, as mattock is upgrading the host OS. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
hi jamesyonan! jamesyonan 21:04:23 hi! mattock 21:04:35 perhaps we can begin, dazo should be here very shortly https://community.openvpn.net/openvpn/wiki/Topics-2011-08-18 21:04:39 vpnHelper 21:04:40 Title: Topics-2011-08-18 â OpenVPN Community (at community.openvpn.net) L'utente dazo_afk è ora conosciuto come dazo 21:04 mattock 21:04:49 ah, here he is dazo 21:04:55 mattock 21:05:01 so, again from the top? dazo 21:05:13 Sorry I'm late mattock 21:05:31 no problem, only a few mins jamesyonan: I assume you have not heard of the community get-together plans? 21:06:04 (summary on topic page) 21:06:18 jamesyonan 21:06:19 no, not yet mattock 21:06:44 what's your take? planning on a trip to Europe at some point (for other reasons)? or just for this 21:07:11 for us Europeans, a long weekend is doable, but from the States... not sure 21:09:03 s7r 21:09:38 looks like microsoft developed a poor imitation of openvpn .. called SSTP secure socket tunneling protocl which uses HTTPS packets and works on port 443 TCP. some SSTP lovers claim it's the equivalent to openvpn but that is a big lie. it works through HTTP proxy, which makes it almost close to openvpn jamesyonan 21:09:40 sure, I'd love to visit Europe s7r 21:09:47 but it can be blocked For any reason, if the network administrator wants to block all outgoing SSTP based VPN connection, then it can be done at the web proxy level. If there is a web proxy (i.e. forward proxy) deployed inside the corporate network which can do filtering of different attributes inside HTTP CONNECT header, then SSTP based connections can be blocked as it adds a fixed field (SSTP_VERSION: *) inside the HTTP CONNECT header. 21:09:52 mattock 21:10:05 s7r: we're in the middle of a meeting, can this wait for a while s7r 21:10:11 do you have any ideas, does openvpn add anything in headers which can be blocked at proxy side? ah okey sorry 21:10:14 mattock 21:11:02 jamesyonan: any preferences on which place / time / occasion would suit you best? Vienna came up as one strong candidate 21:11:22 (for Oct/Nov 2011) 21:11:38 we didn't really think the FOSDEM option that much 21:12:13 yet 21:12:22 the idea was to get as many of the active community members involved as possible (e.g. you, me, dazo, janjust, cron2, andj, etc) 21:12:51 jamesyonan 21:13:13 I think it's a great idea mattock 21:13:13 and, if somehow possible, get a few guys from the America there too (ecrist, krzee)... but that's of course more challenging dazo 21:13:16 my autumn is very hectic already, so if we can think of something next year (q1 or q2), that would increase my chances considerably mattock 21:13:34 yeah, exact timing is not that important I was thinking that we'd need some agenda, but also lots of socializing 21:14:07 cron2 21:14:26 beer mattock 21:14:27 so that it's not _just_ beer and schnitzel dazo 21:15:16 to get some deeper understanding of how the network pieces and how the SSL layer is implemented in openvpn, that could be some good sessions mattock 21:15:28 also plan for OpenVPN 3.0 dazo 21:15:37 yupp mattock 21:15:50 that's probably "next year" stuff anyways jamesyonan 21:16:07 yes, I can certainly attend if we can find a date that works for everyone dazo 21:16:09 maybe a hacking session where we formally start the 3.0 stuff mattock 21:16:36 that would probably take a few days at least? (being optimistic here) 21:16:59 dazo 21:16:59 maybe ... haven't thought of that yet you can get a lot done if 4-5 hours, when you are 2-3+ people doing that .... 21:17:40 *with* not if 21:17:53 mattock 21:18:23 perhaps start a "community get-together" wiki page and plan there? and send mail to openvpn-devel to get more people involved 21:18:50 we might get surprise guests (such as Alon) 21:19:07 anything else on this subject atm? 21:20:02 I can write the first version of the wiki page if you like 21:20:17 dazo 21:20:25 sounds good to me mattock 21:20:47 ok, which topic next? svn merger or 2.2.2 or 2.3? cron2 21:21:03 yes dazo 21:21:04 2.2.2 ... that heavily depends on testing feedback the trac ticket we got (forgot number) is kind of the key reason we want to ship out a 2.2.2 21:21:30 mattock 21:21:37 126? dazo 21:21:48 yes mattock 21:21:50 syspro something dazo 21:21:58 correct when we know where to start looking ... then we can figure out how/when 2.2.2 can be released 21:22:16 mattock 21:22:27 there one more thing... I started looking into the OpenSC/pkcs11-helper/OpenVPN/smartcard issue today that might be 2.2.2 stuff, depending on what it changes 21:22:46 dazo 21:22:48 (I saw Alon released a new version of pkcs11-helper, btw) mattock 21:22:53 yeah, me too I assume it's relatively safe to use that in 2.2.2 21:23:10 dazo 21:23:12 Windows builds should definitely bring that one in yeah, I'd say so 21:23:18 mattock 21:23:42 the changes seemed non-invasive, so I'd say include it oh yes, https://community.openvpn.net/openvpn/ticket/126 still needs testing 21:24:23 vpnHelper 21:24:26 Title: #126 (Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0) â OpenVPN Community (at community.openvpn.net) mattock 21:24:28 hopefully that's coming soon dazo 21:25:01 yeah ... without that, we don't know very well where to start looking in the code mattock 21:25:09 dazo: regarding 2.3 snapshots... have you merged the VS2008 patches yet? praetorian was asking about IPv6-capable Windows snapshots 21:25:23 cron2 21:25:42 mattock: dazo is on merge-strike dazo 21:25:44 mattock: nope, and I don't dare doing much with master before we've sorted out the tmp/svn-merger stuff .... I want to avoid redoing that once again mattock 21:25:50 ah shall we move onto it, then? 21:26:00 cron2 21:26:11 (which is what got me to finally find time to test this stuff ) dazo 21:26:13 yes please! jamesyonan: have you had any chance to look at that stuff yet? 21:26:40 cron2 points out that we need a t_server.sh/t_server.rc framework to run automated server-tests... 21:27 dazo 21:27:23 ack cron2 21:27:39 (I'm not volunteering right now) jamesyonan 21:27:45 dazo: you mean route.[ch] merge? mattock 21:28:08 btw. I'm just upgrading my buildslave host system, so all buildslaves are down should be fixed by end of next week 21:28:25 and the public test server got taken away from us 21:28:38 dazo 21:28:49 jamesyonan: among others ... basically ... the whole merge mattock 21:28:51 but ecrist provided a new one, which I have not yet seen/configured Praetorians 21:29:29 mattock: does the public test system need to be freebsd? mattock 21:29:41 praetorians: not really, no cron2 21:30:14 Praetorians: it could be anything, but "not windows" would make life easier mattock 21:30:15 but I think ecrist created a FreeBSD box for the purpose Praetorians 21:30:44 mattock: ok, I have other vm host servers that I could do linux just not freebsd. mattock 21:30:50 ah, I see dazo 21:30:51 jamesyonan: I need to be sure that I've not messed up things with that merge ... that all your later stuff is included and that the master branch hasn't lost anything jamesyonan 21:31:02 dazo: the basic functionality of the route changes can be tested with ./openvpn --show-gateway mattock 21:32:20 praetorians: if something should go wrong with ecrist's VM, I'm more than happy to take yours jamesyonan 21:32:21 and of course "redirect-gateway block-local" can be tested by verifying that when connected, the client is not able to access any local IP address except the gateway Praetorians 21:32:32 mattock: I can donate a linux vm for the public testingif needed. mattock 21:32:48 ok, thanks! cron2 21:32:58 Thu Aug 18 20:32:54 2011 ROUTE_GATEWAY 193.149.48.190/255.255.255.224 IFACE=eth0 HWADDR=00:22:68:7f:74:20 looks good 21:33:01 Praetorians 21:33:09 mattock: I just didn't have an alternative for the freebsd one. mattock 21:33:40 I fact, our Scientific Linux 6.0 VM got destroyed due to a misunderstanding a while back, too... not going strong on VM front atm praetorians: no problem, didn't mean it that way, sorry 21:34:07 Praetorians 21:35:04 mattock: snapshots snapshots snapshots.. I know what ya mean with vm issues. mattock 21:36:12 yeah, too convenient to create, too convenient to destroy (by mistake) dazo 21:36:42 jamesyonan: so you're giving the merge an ACK if those two things works? jamesyonan 21:37:55 basically, yes cron2 21:38:24 the first one works dazo 21:38:33 --show-gateway? cron2 21:38:39 yep, output pasted above mmmh 21:38:50 dazo 21:39:00 goodie ... then --redirect-gateway block-local should be easy to check cron2 21:39:08 I can even test the second one right now without losing access to IRC etc. - that's all IPv6, and will not be affected by this dazo 21:39:16 cron2: I'd be delighted! 21:39:22 jamesyonan 21:39:30 the problem and the reason for refactoring was that we didn't have a very flexible abstraction layer to make it easy to add new routin g/interface info to the data returned by the platform-specific code. dazo 21:40:46 fair enough ... however, for the 2.3 release, we should probably fix those iproute2 issues cron2 pointed out .... RHEL/Fedora + the clones of these is compiled with --enable-iproute2 by default cron2 21:41:11 193.149.48.190 dev eth0 scope link jamesyonan 21:41:13 the block-local code needed a way to issue route commands where the destination of the route is an interface rather than an IP address cron2 21:41:15 193.149.48.176/28 via 10.100.50.5 dev tun0 193.149.48.192/28 via 10.100.50.5 dev tun0 21:41:16 193.149.48.160/27 dev eth0 proto kernel scope link src 193.149.48.170 metric 202 21:41:19 jamesyonan: you can do that with "ip route" just fine - that's the output of "ip route show" 21:41:37 ip route is so much more powerful than "route add", and much less insanity there 21:41:57 anyway, it does *install* the right routes here, but it doesn't *work* 21:42:52 (I can still ping a neighbour in the LAN) 21:43:07 but that might actually be due to "the openvpn gateway is another box on the local LAN" 21:43:17 ah 21:43:56 noes 21:43:57 the code is borked 21:44:00 the local LAN is 21:44:14 193.149.48.160/27 dev eth0 proto kernel scope link src 193.149.48.170 metric 202 21:44:17 and the two routes installed are 21:44:24 193.149.48.176/28 via 10.100.50.5 dev tun0 21:44:27 193.149.48.192/28 via 10.100.50.5 dev tun0 21:44:27 jamesyonan 21:44:30 yeah, I don't think it will work in that case -- the openvpn box should be external to the local LAN cron2 21:44:35 which is NOT the two /28s that are needed to make up the /27 (with iproute2, one can install a "reject" route, which will make it much clearer that communication isn't supposed to work, instead of sending the packets to the tunnel where they might come back, if public addresses are used) 21:46:19 dazo 21:46:56 and there exists an equivalent for that on Windows too? cron2 21:46:59 in my test case, it not-pings for addresses in the .176/28 half, but it pings fine for addresses in .160/28 - because the code miscalculates the network bits jamesyonan 21:47:00 the basic approach of block-local is to subdivide the local LAN into two smaller subnets and route those subnets into the tunnel, but avoid a routing loop by adding a host route for the LAN gateway cron2 21:47:18 jamesyonan: yeah, that's obvious, but the calculation is failing here (and routing into the tunnel is not exactly the way I'd do "blocking" - if you have official IPs, the packets might come back via the outside path) 21:47:54 jamesyonan 21:48:45 right, but once the packets enter the tunnel, then the server side has full control over filtering them cron2 21:49:03 well, true. jamesyonan 21:49:32 the goal here is to block via routing, which is portable, rather than use platform-specific firewall functionality cron2 finds this statement quite funny, given the amount of #ifdefs in route.c 21:50 cron2 21:50:24 but still, reject routes are not "firewalling" but "routes with an appropriate target" but anyway - that's a side track. The bigger problem is that the calculation is wrong 21:50:35 jamesyonan 21:50:49 the add_block_local_item function in route.c does the subnet division calculation cron2: well there's a clear delineation between portable and non-portable code 21:51:56 the whole point of the refactoring was to define a more sane abstraction layer between the portable and platform specific code 21:52:32 cron2 21:52:57 jamesyonan: I think I understand the thing about portability regarding ifconfig, route, and 10 different unix variants anyway, this code is bogus: 21:53:04 r.netmask = ~(l2-1); 21:53:07 r.network = gateway->addr & r.netmask; 21:53:07 it divides the netmask by 2, and then does the gateway->addr & r.netmask 21:53:26 which fails if the gateway is in the upper half of the network 21:53:32 the r.network bit needs to go before the r.netmask change 21:53:54 ok, here we go 21:55:13 193.149.48.190 dev eth0 scope link 21:55:23 193.149.48.176/28 via 10.100.50.5 dev tun0 21:55:26 193.149.48.160/28 via 10.100.50.5 dev tun0 21:55:26 193.149.48.160/27 dev eth0 proto kernel scope link src 193.149.48.170 metric 202 21:55:26 that's how it should be 21:55:32 http://pastebin.com/8L2EHLbt 21:56:08 committed & mailed 21:59:03 with this change, the branch succeeds in doing --redirect-gateway block-local 21:59:46 jamesyonan 21:59:56 cron2: thanks, that looks good cron2 22:00:51 cool dazo: do you need more? 22:01:17 s7r 22:01:46 mattock: can I get back with my question now? dazo 22:01:49 okay, if that settles the merge ... I'll try to get that done very very soonish .... s7r: not yet 22:01:51 jamesyonan: do you or I pull in cron2's patch? something tells me you might want that patch for AS 22:02:14 mattock 22:02:59 ok, next topic? jamesyonan 22:03:00 dazo: yes, I will probably want to merge that into 2.1 branch dazo 22:03:50 jamesyonan: okay, can you give me a notification when you have committed it ... and I'll make sure to get synch'd up before I push out the new master branch mattock 22:04:10 actually, we only have one topic left: 2.3 cron2 needs a way to tell t_client.sh "this address must NOT ping after connect" 22:04 mattock 22:04:25 unless we covered that topic earlier... cron2 22:04:27 (to test this) mattock 22:04:57 btw. I moved a few old tickets from milestone release-2.2.1 to release-2.2.2 dazo 22:05:11 mattock: can we put 2.3 to next meeting ... just to see how well I'm catching up with the patch queue after this merger mattock 22:05:16 dazo: sure dazo feels the weight of the patch queue 22:05 mattock 22:05:57 one thing perhaps... time and date for next PolarSSL session? cron2 22:05:59 we need to get the svn-merger in, then the winbuildfix, then lots of d12fk windows cleanup, ... dazo 22:06:08 exactly! cron2 22:06:21 and then: testing in earnest mattock 22:06:24 of course, andj is not here but can you guys attend on non-Thursdays? dazo 22:06:27 cron2 22:07:33 I can usually make monday, wednesday or thursday (and in some weeks, none at all). tuesday and friday is usually no-go dazo might ... but is not able to tackle two meetings in a week ... schedule is pretty full, and need recovery time 22:07 mattock 22:08:47 fortunately andj and jamesyonan have done great progress in last few weeks now, if there's nothing else, let's call it a day 22:09:01 cron2 22:09:17 quick meeting today mattock 22:09:23 yeah, I'm surprised dazo is happy 22:09 cron2 22:09:49 dazo: do you have kept overview about all the patches going back and forth? I have lost track, especially about the winbuildfix things mattock 22:10:14 cron2: I'm tracking my own patches + the winbuildfix stuff dazo 22:10:16 I do have a vague overview .... I have a mail filter which star-flags all patches automatically cron2 22:10:35 dazo: ah, cool dazo 22:10:43 mattock: I might need to double check your list against my mails mattock 22:10:52 ok, no problem cron2 22:11:03 feel free to ask dazo 22:11:13 you did give me something some day ... but I think I lost it cron2 22:11:26 dazo: my patches are in your mailbox dazo 22:11:42 hehehe should be an easy search filter 22:11:54 cron2 22:12:12 ("search for mails containing 'rant' and 'bloody murder'"?) dazo 22:12:27 something like that cron2 22:12:31 heh anyway, need to do some more customers-are-waiting-for work 22:12:43 mattock 22:12:58 cron2: see you later! dazo escapes too 22:12 cron2 22:13:01 have a good evening / day mattock 22:13:03 bye everyone! dazo 22:13:08 c'ya! mattock 22:13:09 summary tomorrow as usual dazo 22:13:13 thx!
